Skip site navigation (1) Skip section navigation (2)

Re: BUG #5974: UNION construct type cast gives poor error message

From: Jeff Wu <jwu(at)atlassian(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mike Fowler <mike(at)mlfowler(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5974: UNION construct type cast gives poor error message
Date: 2011-04-18 20:07:21
Message-ID: BANLkTimXh0jHCxED=KL8BcYN5CnyrxkP-Q@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
So I'm a n00b to the open source community, but what needs to happen to get
this fix in?

On 14 April 2011 15:13, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>
> >> That means that all three of the databases you tested have
> >> extensions to the standard similar to what is being contemplated
> >> for PostgreSQL.
> >
> > Uh, no, it proves they all extend the standard to allow NULL to be
> > written without an immediate cast.  Mike's test really fails to
> > prove anything about the point at hand, which is what data type is
> > being imputed to the inner UNION.
>
> The query run was:
>
> SELECT 1,null,null
> UNION
> SELECT 2,3,null
> UNION
> SELECT 3,null,4
>
> It's a bit of a stretch to think that the columns returned from the
> final union weren't integer, or that integer is the default type of
> the union of two nulls.  It's anyone's guess at this point whether
> the third column was unknown during the leftmost union and the type
> set in the next union, or the set of columns involved in the union
> were all evaluated as a group.  If they don't have other literals of
> unknown type it may be hard to discern the implementation details,
> but either I've missed something or we're considering similar user
> visible behavior.
>
> > I don't know those other DBMSes well enough to suggest a test that
> > would be definitive on the point, though.  We'd need something
> > where the choice of datatype is material to the final visible
> > result, and at least in PG that requires some knowledge of
> > not-very-standard behaviors.
>
> If the implementation details for the other databases are that hard
> to discern, how much do we care *how* they do it?  It seems to me
> that the important point here is that they don't throw an error on
> that query and we do.
>
> What am I missing?
>
> -Kevin
>



-- 
Jeff Wu
Marketing Quant, Atlassian
(714) 319-7604

In response to

Responses

pgsql-bugs by date

Next:From: Daniel GraceDate: 2011-04-18 21:31:40
Subject: BUG #5985: CLUSTER ... USING can fail with ERROR: index xxx does not belong to table yyy
Previous:From: BORSCHNECK PascalDate: 2011-04-18 09:16:42
Subject: BUG #5984: Got FailedAssertion("!(opaque->btpo_prev == target)", File: "nbtpage.c", Line: 1166)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group