document pg_settings view doesn't display custom options
Starting separate threads to keep from cluttering the TODO list thread.
Here's a patch for the subject, as mentioned in
/messages/by-id/20201027220555.GS4951@momjian.us
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
doc-pg-settings-no-custom.patchapplication/octet-stream; name=doc-pg-settings-no-custom.patchDownload
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 5bd54cb218..2044ac3855 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -12278,10 +12278,11 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</para>
<para>
- The <structname>pg_settings</structname> view cannot be inserted into or
- deleted from, but it can be updated. An <command>UPDATE</command> applied
- to a row of <structname>pg_settings</structname> is equivalent to executing
- the <command>SET</command> command on that named
+ The <structname>pg_settings</structname> does not display
+ <link linkend="runtime-config-custom">customized options</link>.
+ It cannot be inserted into or deleted from, but it can be updated.
+ An <command>UPDATE</command> applied to a row of <structname>pg_settings</structname>
+ is equivalent to executing the <command>SET</command> command on that named
parameter. The change only affects the value used by the current
session. If an <command>UPDATE</command> is issued within a transaction
that is later aborted, the effects of the <command>UPDATE</command> command
On Wed, Oct 28, 2020 at 2:15 PM John Naylor <john.naylor@enterprisedb.com>
wrote:
Starting separate threads to keep from cluttering the TODO list thread.
Here's a patch for the subject, as mentioned in
/messages/by-id/20201027220555.GS4951@momjian.us
I just realized I introduced a typo, so here's v2.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
v2-doc-pg-settings-no-custom.patchapplication/octet-stream; name=v2-doc-pg-settings-no-custom.patchDownload
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 5bd54cb218..bd70116b90 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -12278,10 +12278,11 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</para>
<para>
- The <structname>pg_settings</structname> view cannot be inserted into or
- deleted from, but it can be updated. An <command>UPDATE</command> applied
- to a row of <structname>pg_settings</structname> is equivalent to executing
- the <command>SET</command> command on that named
+ The <structname>pg_settings</structname> view does not display
+ <link linkend="runtime-config-custom">customized options</link>.
+ It cannot be inserted into or deleted from, but it can be updated.
+ An <command>UPDATE</command> applied to a row of <structname>pg_settings</structname>
+ is equivalent to executing the <command>SET</command> command on that named
parameter. The change only affects the value used by the current
session. If an <command>UPDATE</command> is issued within a transaction
that is later aborted, the effects of the <command>UPDATE</command> command
On 2020/10/29 3:45, John Naylor wrote:
On Wed, Oct 28, 2020 at 2:15 PM John Naylor <john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com>> wrote:
Starting separate threads to keep from cluttering the TODO list thread.
Here's a patch for the subject, as mentioned in
/messages/by-id/20201027220555.GS4951@momjian.usI just realized I introduced a typo, so here's v2.
+ The <structname>pg_settings</structname> view does not display
+ <link linkend="runtime-config-custom">customized options</link>.This is true until the module that defines the customized options is loaded,
but not after that. No? For example, pg_settings displays
pg_stat_statements.max after pg_stat_statements is loaded.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Wed, Oct 28, 2020 at 11:38 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:
On 2020/10/29 3:45, John Naylor wrote:
On Wed, Oct 28, 2020 at 2:15 PM John Naylor <
john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com>> wrote:
Starting separate threads to keep from cluttering the TODO list
thread.
Here's a patch for the subject, as mentioned in
/messages/by-id/20201027220555.GS4951@momjian.us
I just realized I introduced a typo, so here's v2.
+ The <structname>pg_settings</structname> view does not display + <link linkend="runtime-config-custom">customized options</link>.This is true until the module that defines the customized options is
loaded,
but not after that. No? For example, pg_settings displays
pg_stat_statements.max after pg_stat_statements is loaded.
True, how about this:
The <structname>pg_settings</structname> does not display
<link linkend="runtime-config-custom">customized options</link>
that have been set before the relevant extension module has been loaded.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 2020/10/29 21:54, John Naylor wrote:
On Wed, Oct 28, 2020 at 11:38 PM Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>> wrote:
On 2020/10/29 3:45, John Naylor wrote:
On Wed, Oct 28, 2020 at 2:15 PM John Naylor <john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com> <mailto:john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com>>> wrote:
Starting separate threads to keep from cluttering the TODO list thread.
Here's a patch for the subject, as mentioned in
/messages/by-id/20201027220555.GS4951@momjian.usI just realized I introduced a typo, so here's v2.
+ The <structname>pg_settings</structname> view does not display + <link linkend="runtime-config-custom">customized options</link>.This is true until the module that defines the customized options is loaded,
but not after that. No? For example, pg_settings displays
pg_stat_statements.max after pg_stat_statements is loaded.True, how about this:
The <structname>pg_settings</structname> does not display
<link linkend="runtime-config-custom">customized options</link>
that have been set before the relevant extension module has been loaded.
I guess that someone can misread this as
customized options that have been set before the relevant extension
module has been loaded are not displayed even after the module is loaded.
So what about the following, instead?
The pg_settings does not display customized options until the extension
module that defines them has been loaded.
Also I think this note should be in the different paragraph from the paragraph
of "The pg_settings view cannot be inserted into or deleted from...." because
they are different topics. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Thu, Oct 29, 2020 at 11:51 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:
On 2020/10/29 21:54, John Naylor wrote:
The <structname>pg_settings</structname> does not display
<link linkend="runtime-config-custom">customized options</link>
that have been set before the relevant extension module has beenloaded.
I guess that someone can misread this as
customized options that have been set before the relevant extension
module has been loaded are not displayed even after the module is
loaded.So what about the following, instead?
The pg_settings does not display customized options until the
extension
module that defines them has been loaded.Also I think this note should be in the different paragraph from the
paragraph
of "The pg_settings view cannot be inserted into or deleted from...."
because
they are different topics. Thought?
Agreed on both points. In a separate paragraph, I think it's awkward to
start two consecutive sentences with "The pg_settings view". If we put it
in the previous paragraph we could phrase it like this:
"See Section 20.1 for more information about the various ways to change
these parameters. Customized options are not displayed until the
extension module that defines them has been loaded.
The pg_settings view..."
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
John Naylor <john.naylor@enterprisedb.com> writes:
On Thu, Oct 29, 2020 at 11:51 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:Also I think this note should be in the different paragraph from the
paragraph
of "The pg_settings view cannot be inserted into or deleted from...."
because
they are different topics. Thought?
Agreed on both points. In a separate paragraph, I think it's awkward to
start two consecutive sentences with "The pg_settings view". If we put it
in the previous paragraph we could phrase it like this:
"See Section 20.1 for more information about the various ways to change
these parameters. Customized options are not displayed until the
extension module that defines them has been loaded.
That just moves the subject-inconsistency to a different para :-(
I think this item should be its own new para.
As for the repetitiveness, we could just say "This view ...", in one or
even both paras.
regards, tom lane
On Fri, Oct 30, 2020 at 12:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Naylor <john.naylor@enterprisedb.com> writes:
On Thu, Oct 29, 2020 at 11:51 PM Fujii Masao <
masao.fujii@oss.nttdata.com>
wrote:
Also I think this note should be in the different paragraph from the
paragraph
of "The pg_settings view cannot be inserted into or deleted from...."
because
they are different topics. Thought?Agreed on both points. In a separate paragraph, I think it's awkward to
start two consecutive sentences with "The pg_settings view". If we put it
in the previous paragraph we could phrase it like this:"See Section 20.1 for more information about the various ways to change
these parameters. Customized options are not displayed until the
extension module that defines them has been loaded.That just moves the subject-inconsistency to a different para :-(
I think this item should be its own new para.As for the repetitiveness, we could just say "This view ...", in one or
even both paras.
Okay, along those lines here's a patch using "this view" in a new paragraph
for simplicity.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
v3-doc-pg-settings-no-custom.patchapplication/octet-stream; name=v3-doc-pg-settings-no-custom.patchDownload
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 5bd54cb218..c9d3701de7 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -12277,6 +12277,11 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
ways to change these parameters.
</para>
+ <para>
+ This view does not display <link linkend="runtime-config-custom">customized options</link>
+ until the extension module that defines them has been loaded.
+ </para>
+
<para>
The <structname>pg_settings</structname> view cannot be inserted into or
deleted from, but it can be updated. An <command>UPDATE</command> applied
John Naylor <john.naylor@enterprisedb.com> writes:
Okay, along those lines here's a patch using "this view" in a new paragraph
for simplicity.
Basically OK with me, but ...
<quibble>
It seems fairly weird to use a nonspecific reference first and then a
specific one. That is, I'd expect to read "The pg_settings view ..."
and then "This view ...", not the other way around. So we could
put this para second, or put it first but make this para say
"The pg_settings view ..." while the existing text gets reduced to
"This view ...".
Or just make them both say "This view ..." so we don't have to have
this discussion again the next time somebody wants to add a para here.
</quibble>
regards, tom lane
On Fri, Oct 30, 2020 at 12:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Naylor <john.naylor@enterprisedb.com> writes:
Okay, along those lines here's a patch using "this view" in a new
paragraph
for simplicity.
Basically OK with me, but ...
<quibble>
It seems fairly weird to use a nonspecific reference first and then a
specific one. That is, I'd expect to read "The pg_settings view ..."
and then "This view ...", not the other way around. So we could
put this para second, or put it first but make this para say
"The pg_settings view ..." while the existing text gets reduced to
"This view ...".Or just make them both say "This view ..." so we don't have to have
this discussion again the next time somebody wants to add a para here.
</quibble>
Okay, how's this?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
v4-doc-pg-settings-no-custom.patchapplication/octet-stream; name=v4-doc-pg-settings-no-custom.patchDownload
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 5bd54cb218..e2e78c0f46 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -12278,10 +12278,14 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</para>
<para>
- The <structname>pg_settings</structname> view cannot be inserted into or
- deleted from, but it can be updated. An <command>UPDATE</command> applied
- to a row of <structname>pg_settings</structname> is equivalent to executing
- the <command>SET</command> command on that named
+ This view does not display <link linkend="runtime-config-custom">customized options</link>
+ until the extension module that defines them has been loaded.
+ </para>
+
+ <para>
+ This view cannot be inserted into or deleted from, but it can be updated. An
+ <command>UPDATE</command> applied to a row of <structname>pg_settings</structname>
+ is equivalent to executing the <command>SET</command> command on that named
parameter. The change only affects the value used by the current
session. If an <command>UPDATE</command> is issued within a transaction
that is later aborted, the effects of the <command>UPDATE</command> command
On 2020/10/31 2:06, John Naylor wrote:
On Fri, Oct 30, 2020 at 12:48 PM Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
John Naylor <john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com>> writes:
Okay, along those lines here's a patch using "this view" in a new paragraph
for simplicity.Basically OK with me, but ...
<quibble>
It seems fairly weird to use a nonspecific reference first and then a
specific one. That is, I'd expect to read "The pg_settings view ..."
and then "This view ...", not the other way around. So we could
put this para second, or put it first but make this para say
"The pg_settings view ..." while the existing text gets reduced to
"This view ...".Or just make them both say "This view ..." so we don't have to have
this discussion again the next time somebody wants to add a para here.
</quibble>Okay, how's this?
Looks good to me. Barring any objection, I will commit the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2020/11/07 0:42, Fujii Masao wrote:
On 2020/10/31 2:06, John Naylor wrote:
On Fri, Oct 30, 2020 at 12:48 PM Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
John Naylor <john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com>> writes:
> Okay, along those lines here's a patch using "this view" in a new paragraph
> for simplicity.Basically OK with me, but ...
<quibble>
It seems fairly weird to use a nonspecific reference first and then a
specific one. That is, I'd expect to read "The pg_settings view ..."
and then "This view ...", not the other way around. So we could
put this para second, or put it first but make this para say
"The pg_settings view ..." while the existing text gets reduced to
"This view ...".Or just make them both say "This view ..." so we don't have to have
this discussion again the next time somebody wants to add a para here.
</quibble>Okay, how's this?
Looks good to me. Barring any objection, I will commit the patch.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Mon, Nov 9, 2020 at 2:12 AM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:
Pushed. Thanks!
Thank you!
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company