Thread: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
[9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
David G Johnston
Date:
Section 18.1.3 is named "18.1.3. Other Ways to Set Parameters" yet does not reference the ability to use "set_config(...)" to make changes to configuration parameters. Something like (as a final sentence): An alternative to the SQL "SET" command is to use the [link]set_config[link] function. Also, I would suggest modifying the function definitions in table 9-58 to include the data types: current_setting(setting_name text) set_config(setting_name text, new_value text, is_local boolean) David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/9-3-Should-we-mention-set-config-in-18-1-3-in-Server-Configuration-tp5804655.html Sent from the PostgreSQL - docs mailing list archive at Nabble.com.
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
Tom Lane
Date:
David G Johnston <david.g.johnston@gmail.com> writes:
> Section 18.1.3 is named "18.1.3. Other Ways to Set Parameters" yet does not
> reference the ability to use "set_config(...)" to make changes to
> configuration parameters.
Hm, yeah, seems like an oversight.
Another thing I've never been terribly happy about is that pg_settings is
mentioned only in the next sub-section. Could we merge that sub-section
with 18.1.3?
regards, tom lane
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
David Johnston
Date:
Re-sending to hopefully avoid admin moderation rule. Fixing top-post as well.
On Wed, May 21, 2014 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:David G Johnston <david.g.johnston@gmail.com> writes:
> Section 18.1.3 is named "18.1.3. Other Ways to Set Parameters" yet does not
> reference the ability to use "set_config(...)" to make changes to
> configuration parameters.
Hm, yeah, seems like an oversight.
Another thing I've never been terribly happy about is that pg_settings is
mentioned only in the next sub-section. Could we merge that sub-section
with 18.1.3?
regards, tom lane
I am presuming that posting a doc-only patch here instead of -hackers is acceptable.So I finally decided to setup a development environment and generate actual patches. I have few in mind but I thought that these two changes might be quick to implement. I thought wrong - mostly due to my desire to improve things and not just "add and merge" some content.I focused my effort on 18.1.1 to 18.1.4 though the actual coverage of sections 2-4 has changed considerably. I decided not to minimize white-space changes in that region since because of the re-organization git was unable, especially in a couple of instances, to match up before and after anyway. The file itself does not have a consistent format and so I just applied 2-space indentations at each level. I plan to go back and do polishing but I first want to make sure that the end-user product is acceptable.I've only hit this one file for the moment but figure on reviewing all of the relevant cross-references for tweaks and consistency. I already did so in passing and would not expect anything as invasive as what I am proposing here - so if others feel these changes have merit I will plan on taking any ideas and put forth a v2 patch that will hopefully be ready-to-commit.Thank you in advance for any attention and education you can provide.David J.
Attachment
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
David Johnston
Date:
On Wed, May 21, 2014 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:David G Johnston <david.g.johnston@gmail.com> writes:
> Section 18.1.3 is named "18.1.3. Other Ways to Set Parameters" yet does not
> reference the ability to use "set_config(...)" to make changes to
> configuration parameters.
Hm, yeah, seems like an oversight.
Another thing I've never been terribly happy about is that pg_settings is
mentioned only in the next sub-section. Could we merge that sub-section
with 18.1.3?
regards, tom laneI am presuming that posting a doc-only patch here instead of -hackers is acceptable.So I finally decided to setup a development environment and generate actual patches. I have few in mind but I thought that these two changes might be quick to implement. I thought wrong - mostly due to my desire to improve things and not just "add and merge" some content.I focused my effort on 18.1.1 to 18.1.4 though the actual coverage of sections 2-4 has changed considerably. I decided not to minimize white-space changes in that region since because of the re-organization git was unable, especially in a couple of instances, to match up before and after anyway. The file itself does not have a consistent format and so I just applied 2-space indentations at each level. I plan to go back and do polishing but I first want to make sure that the end-user product is acceptable.I've only hit this one file for the moment but figure on reviewing all of the relevant cross-references for tweaks and consistency. I already did so in passing and would not expect anything as invasive as what I am proposing here - so if others feel these changes have merit I will plan on taking any ideas and put forth a v2 patch that will hopefully be ready-to-commit.Thank you in advance for any attention and education you can provide.David J.
Updated the attached PDF (but not the patch) to include a suggested wording to address floating point number rounding and zero treatment.
"disabling log_rotation_age feature."
This addition still needs some work as well as the patch as a whole (see my comments above). The attached PDF is the page that results from "make html"; the original patch has been re-attached as well and -hackers copied given the lack of response on -doc.
I am hoping this change would be something that could be included in 9.4; I believe the enhancements would be most beneficial to newcomers who are just getting started with PostgreSQL and would be using 9.4 as their starting point.
David J.
Attachment
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
Bruce Momjian
Date:
On Thu, Jun 12, 2014 at 11:32:49AM -0400, David Johnston wrote: > This addition still needs some work as well as the patch as a whole (see my > comments above). The attached PDF is the page that results from "make html"; > the original patch has been re-attached as well and -hackers copied given the > lack of response on -doc. > > I am hoping this change would be something that could be included in 9.4; I > believe the enhancements would be most beneficial to newcomers who are just > getting started with PostgreSQL and would be using 9.4 as their starting point. [hackers CC removed] I have reviewed and updated this reworking of our configuration settings documentation and feel it is ready for application to head and 9.4; attached. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
David Johnston
Date:
On Thu, Jun 12, 2014 at 11:32:49AM -0400, David Johnston wrote:
> This addition still needs some work as well as the patch as a whole (see my
> comments above). The attached PDF is the page that results from "make html";
> the original patch has been re-attached as well and -hackers copied given the
> lack of response on -doc.
>
> I am hoping this change would be something that could be included in 9.4; I
> believe the enhancements would be most beneficial to newcomers who are just
> getting started with PostgreSQL and would be using 9.4 as their starting point.
[hackers CC removed]
I have reviewed and updated this reworking of our configuration settings
documentation and feel it is ready for application to head and 9.4;
attached.
Minor corrections:
First block: "
In the first section of this chapter, we describe how to set configuration parameters"
- remove the comma
Second Block:
- placement of the colon inside or outside of the emphasis tag is inconsistent (string, unit, enum are inside; boolean and numeric are outside)
- units: "An numeric value..." -> maybe "An unadorned numeric value...
Third block:
"Hash marks (<literal>#</literal>) designate the remainder of lines as comments." -> "...designate the remainder of the line as a comment." I read this at first as "remaining lines [in the file] ... "
"To embed a single quote in a parameter value, write either two quotes (preferred) or backslash-quote." -> remove the comma
"Querying this view is the sames as" -> "the same as"
"In addition to setting global defaults or attaching" <- add a comma after "defaults"
A few extra commas here-and-there which seem to have replaced my use of colons but that maybe should just be removed completely. If I didn't note it above it seemed OK to leave in (or I missed it entirely...)
David J.
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
Bruce Momjian
Date:
On Tue, Sep 9, 2014 at 03:40:45PM -0400, David Johnston wrote:
> Minor corrections:
>
> First block: "
> In the first section of this chapter, we
> describe how to set configuration parameters"
>
> - remove the comma
>
> Second Block:
> - placement of the colon inside or outside of the emphasis tag is inconsistent
> (string, unit, enum are inside; boolean and numeric are outside)
> - units: "An numeric value..." -> maybe "An unadorned numeric value...
>
> Third block:
> "Hash marks (<literal>#</literal>) designate the remainder of lines as
> comments." -> "...designate the remainder of the line as a comment." I read
> this at first as "remaining lines [in the file] ... "
>
> "To embed a single quote in a parameter value, write either two quotes
> (preferred) or backslash-quote." -> remove the comma
> "Querying this view is the sames as" -> "the same as"
I agree all of the above are improvements, and changed.
> "In addition to setting global defaults or attaching" <- add a comma after
> "defaults"
I didn't like this change as it causes too many comma phrases.
Attaches are the changes since yesterday's patch. The full patch is at:
ftp://momjian.us/postgresql/mypatches/config.diff
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachment
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
David Johnston
Date:
On Tue, Sep 9, 2014 at 03:40:45PM -0400, David Johnston wrote:
> "In addition to setting global defaults or attaching" <- add a comma after
> "defaults"
I didn't like this change as it causes too many comma phrases.
Attaches are the changes since yesterday's patch. The full patch is at:
ftp://momjian.us/postgresql/mypatches/config.diff
At minimum the word "setting" in that paragraph needs to be made plural. ", you can pass settings to <productname>PostgreSQL..."
I'm not particularly fond of the overly long preamble burying the "shell facilities" - and the resultant comma separating the two - but cannot think of anything better. Not having the transition makes it too short and curt. The proposed second comma helped to at least break it up but it too doesn't sound all that great.
I'm good for just making the plural fix and calling it a day.
David J.
Re: [9.3] Should we mention "set_config(...)" in 18.1.3 in Server Configuration?
From
Bruce Momjian
Date:
On Wed, Sep 10, 2014 at 08:09:30PM -0400, David Johnston wrote: > On Wed, Sep 10, 2014 at 4:20 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Tue, Sep 9, 2014 at 03:40:45PM -0400, David Johnston wrote: > > > "In addition to setting global defaults or attaching" <- add a comma > after > > "defaults" > > I didn't like this change as it causes too many comma phrases. > > Attaches are the changes since yesterday's patch. The full patch is at: > > ftp://momjian.us/postgresql/mypatches/config.diff > > > > At minimum the word "setting" in that paragraph needs to be made plural. ", > you can pass settings to <productname>PostgreSQL..." Oh, good point, fixed. > I'm not particularly fond of the overly long preamble burying the "shell > facilities" - and the resultant comma separating the two - but cannot think of > anything better. Not having the transition makes it too short and curt. The > proposed second comma helped to at least break it up but it too doesn't sound > all that great. > > I'm good for just making the plural fix and calling it a day. Modified patch applied to head and 9.4. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +