Обсуждение: Ambiguous usage of 'any' in explanation
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/functions-subquery.html Description: Hi. The [DOC](https://www.postgresql.org/docs/10/static/functions-subquery.html) says: The result is NULL if the comparison does not return false for any subquery row does *any* mean here: some or all? For example in [MySQL](https://dev.mysql.com/doc/refman/8.0/en/any-in-some-subqueries.html) I have found this explanation: >Use of the word SOME is rare, but this example shows why it might be useful. To most people, the English phrase “a is not equal to any b” means “there is no b which is equal to a,” but that is not what is meant by the SQL syntax. The syntax means “there is some b to which a is not equal.” Using <> SOME instead helps ensure that everyone understands the true meaning of the query.
On Sat, Sep 15, 2018 at 11:53:47AM +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/functions-subquery.html > Description: > > Hi. > > The [DOC](https://www.postgresql.org/docs/10/static/functions-subquery.html) > says: > > The result is NULL if the comparison does not return false for any > subquery row > > does *any* mean here: some or all? > > For example in > [MySQL](https://dev.mysql.com/doc/refman/8.0/en/any-in-some-subqueries.html) > I have found this explanation: > > >Use of the word SOME is rare, but this example shows why it might be > useful. To most people, the English phrase “a is not equal to any b” means > “there is no b which is equal to a,” but that is not what is meant by the > SQL syntax. The syntax means “there is some b to which a is not equal.” > Using <> SOME instead helps ensure that everyone understands the true > meaning of the query. I am kind of confused by this report. You mention SOME in the text above, which is a synonym for ANY, but the text you quote: > The result is NULL if the comparison does not return false for any > subquery row is from ALL: The result of <token>ALL</token> is <quote>true</quote> if the comparison returns true for all subquery rows (including the case where the subquery returns no rows). The result is <quote>false</quote> if the comparison returns false for any subquery row. The result is NULL if the comparison does not return false for any subquery row, and it returns NULL for at least one row. I see the last line is just trying to negate the line above it, but the mix of "not" and "any" is confusing. I can reword this last line to be: 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? -- Bruce Momjian <bruce@momjian.us> 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 +
Вложения
On Thursday, October 11, 2018, Bruce Momjian <bruce@momjian.us> 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?
+1
David J.
On Fri, Oct 12, 2018 at 01:42:03PM +0300, KES wrote: > - 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 false > The result of ANY is NULL if no one row yelds true and at least one row yields > NULL > When subquery return no rows the result of ANY is "false" > > sentences are short, easy to spot when and how result is changed 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. 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 <comparison> ANY that is being used. -- Bruce Momjian <bruce@momjian.us> 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 +
On Fri, Oct 12, 2018 at 8:04 AM Bruce Momjian <bruce@momjian.us> 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 <comparison> 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.
On Fri, Oct 12, 2018 at 02:37:33PM -0700, David G. Johnston wrote: > On Fri, Oct 12, 2018 at 8:04 AM Bruce Momjian <bruce@momjian.us> 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. I meant that each row feeds a value to the left-hand side to be evaluated. > 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 <comparison> 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) Sure. -- Bruce Momjian <bruce@momjian.us> 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 +
On Sat, Oct 13, 2018 at 12:25:38PM +0300, KES wrote: > >or NULL if any of the comparisons result in unknown > result in unknown?? Well, SQL has a three-valued logic, and UNKOWN values are treated like NULL. For me they have always been the same, and I would like to avoid "unknown" in this context, if possible. --------------------------------------------------------------------------- > 13.10.2018, 00:37, "David G. Johnston" <david.g.johnston@gmail.com>: > > On Fri, Oct 12, 2018 at 8:04 AM Bruce Momjian <bruce@momjian.us> 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 <comparison> 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. > > -- Bruce Momjian <bruce@momjian.us> 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 +
On Saturday, October 13, 2018, Bruce Momjian <bruce@momjian.us> wrote:
On Sat, Oct 13, 2018 at 12:25:38PM +0300, KES wrote:
> >or NULL if any of the comparisons result in unknown
> result in unknown??
Well, SQL has a three-valued logic, and UNKOWN values are treated like
NULL. For me they have always been the same, and I would like to avoid
"unknown" in this context, if possible.
I was just trying to avoid using the word null twice in the same sentence but it’s not a strong aversion.
David J.
On Sun, Oct 14, 2018 at 11:00:18PM -0700, David G. Johnston wrote: > On Saturday, October 13, 2018, Bruce Momjian <bruce@momjian.us> wrote: > > On Sat, Oct 13, 2018 at 12:25:38PM +0300, KES wrote: > > >or NULL if any of the comparisons result in unknown > > result in unknown?? > > Well, SQL has a three-valued logic, and UNKOWN values are treated like > NULL. For me they have always been the same, and I would like to avoid > "unknown" in this context, if possible. > > > > I was just trying to avoid using the word null twice in the same sentence but > it’s not a strong aversion. I am thinking of applying my earlier patch and calling it done. -- Bruce Momjian <bruce@momjian.us> 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 +
On Mon, Oct 15, 2018 at 12:32:20PM -0400, Bruce Momjian wrote: > On Sun, Oct 14, 2018 at 11:00:18PM -0700, David G. Johnston wrote: > > On Saturday, October 13, 2018, Bruce Momjian <bruce@momjian.us> wrote: > > > > On Sat, Oct 13, 2018 at 12:25:38PM +0300, KES wrote: > > > >or NULL if any of the comparisons result in unknown > > > result in unknown?? > > > > Well, SQL has a three-valued logic, and UNKOWN values are treated like > > NULL. For me they have always been the same, and I would like to avoid > > "unknown" in this context, if possible. > > > > > > > > I was just trying to avoid using the word null twice in the same sentence but > > it’s not a strong aversion. > > I am thinking of applying my earlier patch and calling it done. Applied and backpatched to 9.3. -- Bruce Momjian <bruce@momjian.us> 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 +