On Tue, Sep 10, 2013 at 1:54 PM, Bruce Momjian wrote:
> On Tue, Sep 10, 2013 at 10:50:32AM -0400, Bruce Momjian wrote:
>> > have to hit all the targets. If not, I'd either A: leave things alone
>> > or B: remove the special case logic in IS NULL (so that it behaves as
>> > coalesce() does) and do
Bruce Momjian wrote:
> FYI, I think these queries below prove that NOT NULL constraints do not
> follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> and that my patch was trying to promote for queries:
>
> CREATE TABLE test2(x test NOT NULL);
> CREATE TABLE
> INS
On Tue, Sep 10, 2013 at 12:48:08PM -0700, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > FYI, I think these queries below prove that NOT NULL constraints do not
> > follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> > and that my patch was trying to promote for queries:
Bruce Momjian wrote:
> Is IS DISTINCT FROM correct though?
>
> SELECT ROW(NULL) IS DISTINCT FROM NULL;
> ?column?
> --
> t
> (1 row)
My recollection from previous discussions is that this is what is
required by the standard. ROW(NULL) IS NULL, but it is DISTINCT
FROM
On Tue, Sep 10, 2013 at 10:50:32AM -0400, Bruce Momjian wrote:
> > have to hit all the targets. If not, I'd either A: leave things alone
> > or B: remove the special case logic in IS NULL (so that it behaves as
> > coalesce() does) and document our divergence from the standard. Point
> > being: B
On Tue, Sep 10, 2013 at 09:12:08AM -0500, Merlin Moncure wrote:
> > FYI, I think these queries below prove that NOT NULL constraints do not
> > follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> > and that my patch was trying to promote for queries:
> >
> > CREATE TAB
On Tue, Sep 10, 2013 at 8:56 AM, Bruce Momjian wrote:
> On Tue, Sep 10, 2013 at 08:45:14AM -0400, Robert Haas wrote:
>> On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
>> > The problem is that I don't believe this patch is commit-ready ---
>> > someone needs to research the IS NULL tests in
On Tue, Sep 10, 2013 at 08:45:14AM -0400, Robert Haas wrote:
> On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
> > The problem is that I don't believe this patch is commit-ready ---
> > someone needs to research the IS NULL tests in all areas of our code to
> > see if they match this patch, a
On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
> The problem is that I don't believe this patch is commit-ready ---
> someone needs to research the IS NULL tests in all areas of our code to
> see if they match this patch, and I can't do that. Is that something a
> reviewer is going to be wi
On Mon, Sep 9, 2013 at 12:37:25PM -0400, Robert Haas wrote:
> On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian wrote:
> >> Why don't you add the proposal to the commitfest?
> >
> > This issue is so much larger than the patch's validity that I don't see
> > how that would work.
>
> I hate to be rud
On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian wrote:
>> Why don't you add the proposal to the commitfest?
>
> This issue is so much larger than the patch's validity that I don't see
> how that would work.
I hate to be rude here, but I think you're being ridiculous. We have
a well-established pr
On Sat, Sep 7, 2013 at 10:59:08AM -0400, Bruce Momjian wrote:
> My original problem report was November, 2012:
>
> http://www.postgresql.org/message-id/50b3d11f.20...@2ndquadrant.com
>
> and my patch to fix this was July 4. Tom gave me a code snipped to test
> PL/pgSQL's handling of recor
On Sat, Sep 7, 2013 at 07:42:55AM +0200, Andres Freund wrote:
> On 2013-09-06 23:07:04 -0400, Bruce Momjian wrote:
> > On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> > > >> Another poss
On 2013-09-06 23:07:04 -0400, Bruce Momjian wrote:
> On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> > >> Another possible fix would be to avoid the IS NULL value optimizer
> > >> expansion i
On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> >> Another possible fix would be to avoid the IS NULL value optimizer
> >> expansion if a ROW construct is inside a ROW(). I have attached a patch
Bruce Momjian writes:
> On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
>> Another possible fix would be to avoid the IS NULL value optimizer
>> expansion if a ROW construct is inside a ROW(). I have attached a patch
>> that does this for review.
> Having received no replies, do p
On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> Another possible fix would be to avoid the IS NULL value optimizer
> expansion if a ROW construct is inside a ROW(). I have attached a patch
> that does this for review.
Having received no replies, do people perfer this version of t
On Thu, Sep 5, 2013 at 02:14:39PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
> >> I have not heard any feedback on this patch, so I would like to apply it
> >> to give us a nested ROW/IS NULL API we can document. It would have to
> >> b
Robert Haas writes:
> On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
>> I have not heard any feedback on this patch, so I would like to apply it
>> to give us a nested ROW/IS NULL API we can document. It would have to
>> be marked in the release notes as a backward incompatibility.
> I do
On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian wrote:
> On Tue, Sep 3, 2013 at 09:32:44PM -0400, Bruce Momjian wrote:
>> In this test, SELECT NULL (which internally would produce SELECT
>> ROW(NULL)), returns TRUE, while SELECT ROW(NULL) and further nesting
>> returns false.
>>
>> This has made me
On Tue, Sep 3, 2013 at 09:32:44PM -0400, Bruce Momjian wrote:
> In this test, SELECT NULL (which internally would produce SELECT
> ROW(NULL)), returns TRUE, while SELECT ROW(NULL) and further nesting
> returns false.
>
> This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> NULL
On Tue, Sep 3, 2013 at 09:44:33PM -0500, Merlin Moncure wrote:
> It gets worse and worse. The IS NULL operator is already pretty much
> special cased -- in just about all other case concerning rowtypes (for
> example coalesce) 'null containing rowtypes are *not* considered to be
> null as the con
On Tue, Sep 3, 2013 at 10:27:38PM -0400, Tom Lane wrote:
> I wrote:
> > And I will say once more that a patch that affects only the behavior of
> > eval_const_expressions can be rejected on its face. That code has to be
> > kept in sync with the behavior of execQual.c, not just whacked around by
On Tue, Sep 3, 2013 at 09:43:14PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> > NULL returns true, and any further nesting returns false.
>
> AFAICS, the only good argument for breaking backwards compatibility here
> i
On Tue, Sep 3, 2013 at 8:32 PM, Bruce Momjian wrote:
> On Fri, Jul 5, 2013 at 10:21:19AM -0400, Bruce Momjian wrote:
>> On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
>> > Bruce Momjian writes:
>> > > I developed the attached patch which properly recurses into ROW()
>> > > records che
I wrote:
> And I will say once more that a patch that affects only the behavior of
> eval_const_expressions can be rejected on its face. That code has to be
> kept in sync with the behavior of execQual.c, not just whacked around by
> itself. And then there are the NOT NULL constraint cases to wor
Bruce Momjian writes:
> This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> NULL returns true, and any further nesting returns false.
AFAICS, the only good argument for breaking backwards compatibility here
is if you can convince people that the new behavior is more conformant
On Fri, Jul 5, 2013 at 10:21:19AM -0400, Bruce Momjian wrote:
> On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I developed the attached patch which properly recurses into ROW()
> > > records checking for NULLs; you can see it returns the right answer in
Peter Eisentraut wrote:
> On 7/4/13 5:06 PM, Alvaro Herrera wrote:
> > FWIW if changing the behavior of NOT NULL constraints is desired, I
> > still have the patch to catalogue them around, if anyone wants to play
> > around. I haven't gotten around to finishing it up, yet :-(
>
> If your latest
On Sun, Jul 7, 2013 at 01:04:05PM -0400, Bruce Momjian wrote:
> Looks like I have to modify ExecEvalNullTest().
Oops, I mean ExecConstraints(). This could be tricky.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impos
On Fri, Jul 5, 2013 at 11:03:56AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
> >> No, it isn't, or at least it's far from the only place. If we're going
> >> to change this, we would also want to change the behavior of tests on
>
On Fri, Jul 5, 2013 at 12:43:57PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Should I just mark this as a TODO?
>
> I thought it was on the list already.
We only have:
Improve handling of NULLs in arrays
and some pl/pgsql items regarding nulls.
--
Bruce Momjian h
Bruce Momjian writes:
> Should I just mark this as a TODO?
I thought it was on the list already.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Fri, Jul 5, 2013 at 11:03:56AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
> >> No, it isn't, or at least it's far from the only place. If we're going
> >> to change this, we would also want to change the behavior of tests on
>
Bruce Momjian writes:
> On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
>> No, it isn't, or at least it's far from the only place. If we're going
>> to change this, we would also want to change the behavior of tests on
>> RECORD values, which is something that would have to happen at ru
On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I developed the attached patch which properly recurses into ROW()
> > records checking for NULLs; you can see it returns the right answer in
> > all cases (and constant folds too):
>
> My recollection of the pr
On 7/4/13 5:06 PM, Alvaro Herrera wrote:
> FWIW if changing the behavior of NOT NULL constraints is desired, I
> still have the patch to catalogue them around, if anyone wants to play
> around. I haven't gotten around to finishing it up, yet :-(
If your latest patch isn't publicly available, I'd
Tom Lane wrote:
> My recollection of the previous discussion is that we didn't have
> consensus on what the "right" behavior is, so I'm not sure you can just
> assert that this patch is right. In any case this is only touching the
> tip of the iceberg. If we intend that rows of nulls should be n
Bruce Momjian writes:
> I developed the attached patch which properly recurses into ROW()
> records checking for NULLs; you can see it returns the right answer in
> all cases (and constant folds too):
My recollection of the previous discussion is that we didn't have
consensus on what the "right"
On Mon, Nov 26, 2012 at 09:29:19PM +0100, Hannu Krosing wrote:
> On 11/26/2012 09:05 PM, Tom Lane wrote:
> >Hannu Krosing writes:
> >>In some previous mail Tom Lane claimed that by SQL standard
> >>either an array of all NULLs or a record with all fields NULLs (I
> >>don't remember which) is also
40 matches
Mail list logo
