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 wrote:
> >
> > On Sat, Oct 13, 2018 at 12:25:38PM +0300, KES wrote:
> > > >or NULL if any of the comparisons
On Sun, Oct 14, 2018 at 11:00:18PM -0700, David G. Johnston wrote:
> On Saturday, October 13, 2018, Bruce Momjian 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 t
On Saturday, October 13, 2018, Bruce Momjian 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 b
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
>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, a
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 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...t
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-ha
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 compari
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 lea
- 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
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?
>
+1
Da
On Sat, Sep 15, 2018 at 11:53:47AM +, 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/f
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 retu
13 matches
Mail list logo