Re: Documentation does not cover multiple WITH in one query

[KES]

Thank you. That is I am looking for.
Never thought that 'WITH' syntax is described at 'SELECT'. 

Will be very helpful if this will be mentioned on this page: 
https://www.postgresql.org/docs/10/static/queries-with.html
For an example:

   [ WITH [ RECURSIVE ] with_query [, ...] ]

and with_query is shown as:

   with_query_name [ ( column_name [, ...] ) ] AS ( select | values | 
insert | update | delete )

For full syntax of `WITH` see 
https://www.postgresql.org/docs/10/static/sql-select.html


Thanks.

24.08.2018, 23:30, "Bruce Momjian" :
> On Wed, Aug 22, 2018 at 09:24:52AM +, PG Doc comments form wrote:
>>  The following documentation comment has been logged on the website:
>>
>>  Page: https://www.postgresql.org/docs/10/static/queries-with.html
>>  Description:
>>
>>  Hi. I have found
>>  [DOC](https://www.postgresql.org/docs/10/static/queries-with.html)
>>
>>  it is fine, but did not cover multiple WITH in one query.
>>
>>  I found answer only [here](https://stackoverflow.com/a/38137037/4632019)
>>
>>  May you please add the example:
>>
>>  WITH table1 AS (...), table2 AS (...) SELECT * FROM table1, table2
>
> Well, the SELECT manual has:
>
>    [ WITH [ RECURSIVE ] with_query [, ...] ]
>
> and with_query is shown as:
>
>    with_query_name [ ( column_name [, ...] ) ] AS ( select | values | 
> insert | update | delete )
>
> This is standard SQL. I don't think we are going to be able to show
> every possible syntax.
>
> --
>   Bruce Momjian  http://momjian.us
>   EnterpriseDB http://enterprisedb.com
>
> + As you are, so once was I. As I am, so you will be. +
> + Ancient Roman grave inscription +

Re: Ambiguous usage of 'any' in explanation

[KES]

-   The result is NULL if the comparison does not return true for any row,+   The result is NULL if no comparison with a subquery row returns true,    and it returns NULL for at least one row.-The result of ANY is “true” if the comparison returns true for any subquery row. The result is “false” if the comparison returns false for every subquery row (including the case where the subquery returns no rows). The result is NULL if the comparison does not return true for any row, and it returns NULL for at least one row. Similary to:>The result of ALL is "false" even if *at least one*  row yield false +The result of ANY is "true" if at least one row yields true.The result of ANY is "false" if all rows yield falseThe result of ANY is NULL if no one row yelds true and at least one row yields NULLWhen subquery return no rows the result of ANY is "false" sentences are short, easy to spot when and how result is changed   12.10.2018, 00:20, "David G. Johnston" :On Thursday, October 11, 2018, Bruce Momjian  wrote:         The result is NULL if no comparison with a subquery row returns        false, and it returns NULL for at least one row.I can make similar adjustments in other places, and have attached a docpatch.  Does that help? +1 David J. 

Re: Ambiguous usage of 'any' in explanation

[KES]

either it is hard to understand. I will rephrase one part to show how it is easy to understand from my side:>ALL> The result is “false” if any false result is found. The result of ALL is "false" even if *at least one*  row yield false(we can use 'some' word here, but it is not such clear as *at least one*) This sentence is easyly can be compared to: >The result of ALL is “true” if all rows yield true We can notice difference with first statement so can understand when result is different:(I got next picture in my mind in this case:)    all true -> true   at least one false -> false  Thus if other parts of DOC would be constructed in same manner, it would be cool PS. When DOC not just document behavior but also allow eaisly detect difference when/why behavior of a command is changed. Thank you.12.10.2018, 00:20, "David G. Johnston" :On Thursday, October 11, 2018, Bruce Momjian  wrote:
        The result is NULL if no comparison with a subquery row returns
        false, and it returns NULL for at least one row.

I can make similar adjustments in other places, and have attached a doc
patch.  Does that help?
+1David J. 

Re: Ambiguous usage of 'any' in explanation

[KES]

>or NULL if any of the comparisons result in unknownresult in unknown?? 13.10.2018, 00:37, "David G. Johnston" :On Fri, Oct 12, 2018 at 8:04 AM Bruce Momjian  wrote:Sorry, but I don't like this wording.  The problem is that the
comparison has two row sets --- the left-hand side, and the right-hand
side.Huh...the left hand side must be a non-set scalar or row constructor.  Each row on the left-hand side is compared with the row set on
the right.  I also don't like people thinking about the result of ANY
since it is really  ANY that is being used.Then there is some more rewording to be done since: "The result of ANY is “true” if any true result is obtained." (v10; 9.22.4)Maybe:The result of ANY is “true” if the comparison returns true for any subquery row; otherwise the result is “false” (or NULL if any of the comparisons result in unknown)David J.

Re: Unexpected behaviour: it was documented to return the same value

[KES]

I would prefer to remove the option from the configuration list instead of having it reset to empty string. Eg. set_config( 'my.option', NULL, false ) Having it to return the empty string cause differences in the behaviour when parameter is not recognized at all and when it setup to default. How to make it "unrecognizable" again using set_config/RESET? The exact problem I am trying to resolve was asked here: https://stackoverflow.com/q/50923911/4632019 
        Кому: kes-...@yandex.ru (kes-...@yandex.ru), pgsql-docs@lists.postgresql.org (pgsql-docs@lists.postgresql.org);

Тема: Unexpected behaviour: it was documented to return the same value;
07.07.2025, 17:40, "David G. Johnston" :
On Mon, Jul 7, 2025 at 6:51 AM David G. Johnston <david.g.johns...@gmail.com> wrote:On Saturday, July 5, 2025, PG Doc comments form <nore...@postgresql.org> wrote:The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/17/functions-admin.html
Description:Yeah, this clarification just wasn't back-patched.https://www.postgresql.org/docs/18/functions-admin.html#FUNCTIONS-ADMIN-SET"set_config accepts the NULL value for new_value, but as settings cannot be null, it is interpreted as a request to reset the setting to its default value."David J.

Re: Unexpected behaviour: it was documented to return the same value

[KES]

I suppose that DEFAULT syntax should be used to set setting to its default value. Eg.set_config( 'my.option', DEFAULT, false )This is clear what should happen here. Also this syntax will correspond to other places, eg. INSERT INTO xx (name) VALUES (DEFAULT). Using NULL to set reset the value to the default is very very confusing.set_config( 'my.option', NULL, false )Expected: this call should make option unrecognizable again.
Кому: David G. Johnston (david.g.johns...@gmail.com), pgsql-docs@lists.postgresql.org (pgsql-docs@lists.postgresql.org);

Тема: Unexpected behaviour: it was documented to return the same value;
13.07.2025, 16:34, "KES" :
I would prefer to remove the option from the configuration list instead of having it reset to empty string. Eg. set_config( 'my.option', NULL, false ) Having it to return the empty string cause differences in the behaviour when parameter is not recognized at all and when it setup to default. How to make it "unrecognizable" again using set_config/RESET? The exact problem I am trying to resolve was asked here: https://stackoverflow.com/q/50923911/4632019 
    Кому: kes-...@yandex.ru (kes-...@yandex.ru), pgsql-docs@lists.postgresql.org (pgsql-docs@lists.postgresql.org);

Тема: Unexpected behaviour: it was documented to return the same value;
07.07.2025, 17:40, "David G. Johnston" <david.g.johns...@gmail.com>:
On Mon, Jul 7, 2025 at 6:51 AM David G. Johnston <david.g.johns...@gmail.com> wrote:On Saturday, July 5, 2025, PG Doc comments form <nore...@postgresql.org> wrote:The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/17/functions-admin.html
Description:Yeah, this clarification just wasn't back-patched.https://www.postgresql.org/docs/18/functions-admin.html#FUNCTIONS-ADMIN-SET"set_config accepts the NULL value for new_value, but as settings cannot be null, it is interpreted as a request to reset the setting to its default value."David J.