Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread Tom Lane
Peter Eisentraut writes: > On 7/26/16 7:46 PM, Thomas Munro wrote: >> By the way, our documentation says that NOT NULL constraints are >> equivalent to CHECK (column_name IS NOT NULL). That is what the SQL >> standard says, but in fact our NOT NULL constraints

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread Peter Eisentraut
On 7/26/16 7:46 PM, Thomas Munro wrote: > By the way, our documentation says that NOT NULL constraints are > equivalent to CHECK (column_name IS NOT NULL). That is what the SQL > standard says, but in fact our NOT NULL constraints are equivalent to > CHECK (column_name IS DISTINCT FROM NULL).

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread Thomas Munro
On Wed, Jul 27, 2016 at 7:35 AM, Tom Lane wrote: > "David G. Johnston" writes: >> The concept embodied by "NULL" in the operator "IS [NOT] NULL" is distinct >> from the concept embodied by "NULL" in the operator "IS [NOT] DISTINCT >> FROM". > >> In

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread Tom Lane
"David G. Johnston" writes: > The concept embodied by "NULL" in the operator "IS [NOT] NULL" is distinct > from the concept embodied by "NULL" in the operator "IS [NOT] DISTINCT > FROM". > In short, the former smooths out the differences between composite and >

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread David G. Johnston
On Tue, Jul 26, 2016 at 11:10 AM, Tom Lane wrote: > > 3. Andrew also revived the bug #7808 thread in which it was complained > that ExecMakeTableFunctionResult should not fail on null results from > functions returning SETOF composite. That's related only in that the >

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread Tom Lane
Peter Eisentraut writes: > On 7/22/16 7:01 PM, Andrew Gierth wrote: >> In light of the fact that it is an endless cause of bugs both in pg and >> potentially to applications, I propose that we cease attempting to >> conform to the spec's definition of IS NULL in

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-26 Thread Kevin Grittner
On Mon, Jul 25, 2016 at 8:28 PM, Peter Eisentraut wrote: > On 7/22/16 7:01 PM, Andrew Gierth wrote: >> In light of the fact that it is an endless cause of bugs both in pg and >> potentially to applications, I propose that we cease attempting to >> conform to the

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-25 Thread Peter Eisentraut
On 7/22/16 7:01 PM, Andrew Gierth wrote: > In light of the fact that it is an endless cause of bugs both in pg and > potentially to applications, I propose that we cease attempting to > conform to the spec's definition of IS NULL in favour of the following > rules: I can't see how we would

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread Andrew Gierth
> "Andrew" == Andrew Gierth writes: >>> Whole-row vars when constructed never contain the null value. David> ...but what does this mean in end-user terms?​ Andrew> It means for example that this query: Andrew> select y from x left join y on (x.id=y.id)

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread Jim Nasby
On 7/22/16 8:05 PM, David G. Johnston wrote: I would expect that >95% of cases where someone has written (x IS NOT NULL) for x being a composite type, it's actually a bug and that NOT (x IS NULL) was intended. Yeah, it would need to be targeted there. I agree with the numbers and

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread David G. Johnston
On Friday, July 22, 2016, Andrew Gierth wrote: > > "David" == David G Johnston > writes: > > >> Prohibiting IS NOT NULL is not on the cards; it's very widely used. > > David> ​Yet changing how it behaves, invisibly,

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread Andrew Gierth
> "David" == David G Johnston writes: >> Prohibiting IS NOT NULL is not on the cards; it's very widely used. David> ​Yet changing how it behaves, invisibly, is? Did you mean prohibiting it only for composite-type args? It's obviously widely used for

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread David G. Johnston
On Fri, Jul 22, 2016 at 8:04 PM, Andrew Gierth wrote: > > "David" == David G Johnston writes: > > >> 2. x IS NOT NULL if and only if NOT (x IS NULL) > > David> ​I would rather prohibit "IS NOT NULL" altogether.​ If one needs >

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread Andrew Gierth
> "David" == David G Johnston writes: >> 1. x IS NULL is true if and only if x has the null value (isnull set). David> ​I don't have a problem conforming to "ROW(NULL, NULL) IS NULL" David> being true...​if you somehow get a hold of something in that David>

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread Andrew Gierth
> "David" == David G Johnston writes: >> 2. x IS NOT NULL if and only if NOT (x IS NULL) David> ​I would rather prohibit "IS NOT NULL" altogether.​ If one needs David> to test "NOT (x IS NULL)" they can write it that way. Prohibiting IS NOT NULL is not on

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

2016-07-22 Thread David G. Johnston
On Fri, Jul 22, 2016 at 7:01 PM, Andrew Gierth wrote: > In light of the fact that it is an endless cause of bugs both in pg and > potentially to applications, I propose that we cease attempting to > conform to the spec's definition of IS NULL in favour of the