PL/pgSQL casing
There are a few instances of PL/PgSQL in the docs, the attached changes the casing on those to PL/pgSQL which we use consistently otherwise. -- Daniel Gustafsson https://vmware.com/ plpgsql_casing.diff Description: Binary data
Re: PL/pgSQL casing
pá 2. 9. 2022 v 11:38 odesílatel Daniel Gustafsson napsal: > There are a few instances of PL/PgSQL in the docs, the attached changes the > casing on those to PL/pgSQL which we use consistently otherwise. > +1 Pavel > -- > Daniel Gustafsson https://vmware.com/ > >
No discussion of custom variables; no "See also" for set_config, current_setting, pg_settings
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/sql-set.html Description: A reader of this section https://www.postgresql.org/docs/current/sql-set.html of the documentation might be forgiven for thinking that Postgres does not support custom variables. There are also related commands and features that are not mentioned. These might be covered by a reference to 20.1.3, but that section also does not mention custom variables afaict. I'd be happy to write some better documentation (for all the sections in question). I think actually a separate section under 20.1 that could be referred to from SET, SHOW etc might be best. I've contributed to the documentation before, but I forget how. A description of how at the bottom of the Documentation home page or at least in the FAQ might be in order also.
Re: No discussion of custom variables; no "See also" for set_config, current_setting, pg_settings
On Friday, September 2, 2022, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/sql-set.html > Description: > > A reader of this section > https://www.postgresql.org/docs/current/sql-set.html of the documentation > might be forgiven for thinking that Postgres does not support custom > variables. > > There are also related commands and features that are not mentioned. These > might be covered by a reference to 20.1.3, but that section also does not > mention custom variables afaict. 20.16 “Customized Options” is how this is labelled in the documentation. > I'd be happy to write some better documentation (for all the sections in > question). I think actually a separate section under 20.1 that could be > referred to from SET, SHOW etc might be best. I’m doubting that mentioning customized variables everywhere in the documentation besides the chapter that explains that they (and all other settings) exist is a benefit. > > I've contributed to the documentation before, but I forget how. A > description of how at the bottom of the Documentation home page or at least > in the FAQ might be in order also. > Usually just post concrete ideas to -hackers or -bugs, or even -docs. The good ones tend to get implemented even without a patch of the sgml provided. Otherwise, read: https://www.postgresql.org/docs/current/docguide.html There is also existing material out there on contributing patches, it applies even if those patches only touch the documentation. David J.
Re: No discussion of custom variables; no "See also" for set_config, current_setting, pg_settings
PG Doc comments form writes: > A reader of this section > https://www.postgresql.org/docs/current/sql-set.html of the documentation > might be forgiven for thinking that Postgres does not support custom > variables. They are, in fact, *not* a supported feature. The only intended use of non-core GUCs was for extensions' parameters. People have abused the mechanism to create ad-hoc session variables, but we don't encourage it. The underlying code won't scale to large numbers of variables, there's no way to declare properties of such a variable in SQL, etc. There's been an ongoing effort to create a respectable substitute, but it still hasn't gotten across the finish line [1]. regards, tom lane [1] https://commitfest.postgresql.org/39/1608/
Re: No discussion of custom variables; no "See also" for set_config, current_setting, pg_settings
Thanks for the quick response. It’s a clearly useful, simplifying feature. Unless it is likely to be removed at some point, I propose it should be documented and declared supported wherever relevant. In any event, I am happy to prepare some documentation changes that mention these caveats, but I won’t if there is no chance of it being accepted. Are we totally opposed? > On Sep 2, 2022, at 15:16 , Tom Lane wrote: > > PG Doc comments form writes: >> A reader of this section >> https://www.postgresql.org/docs/current/sql-set.html of the documentation >> might be forgiven for thinking that Postgres does not support custom >> variables. > > They are, in fact, *not* a supported feature. The only intended use > of non-core GUCs was for extensions' parameters. People have abused the > mechanism to create ad-hoc session variables, but we don't encourage it. > The underlying code won't scale to large numbers of variables, there's > no way to declare properties of such a variable in SQL, etc. > > There's been an ongoing effort to create a respectable substitute, > but it still hasn't gotten across the finish line [1]. > > regards, tom lane > > [1] https://commitfest.postgresql.org/39/1608/
Re: [PATCH] doc/queries.sgml: add missing comma
On Tue, Aug 30, 2022 at 02:18:42PM -0400, Bruce Momjian wrote: > On Wed, Aug 24, 2022 at 07:58:04PM +0200, Peter Eisentraut wrote: > > On 18.08.22 20:10, Bruce Momjian wrote: > > > > Thus: > > > > Strictly speaking, this process is iteration, but > > > > RECURSIVE > > > > is the terminology chosen by the SQL standards committee." > > > > > > > > Because the above sounds just fine, I'd argue that if one does leave > > > > "not > > > > recursion" it should be set off by a comma. > > > I went with new wording, which should make this even clearer; patch > > > attached. > > > > I think this whole note is a bit misleading, like the SQL people don't know > > what recursion is. The point is that the query is defined recursively. The > > evaluation process is iterative. Those two are not contradictions. > > Okay, makes sense. Here is an updated patch. Patch applied back to PG 10. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
Re: Duplicate text in ANALYZE related to inheritance/parents
On Wed, Aug 31, 2022 at 11:43:30PM -0400, Bruce Momjian wrote: > I noticed that our ANALYZE documentation has confusing duplicate text > related to the analyzing of inheritance trees. This patch fixes it. Patch applied back to PG 10. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
