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

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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Jeff Wu" <jwu(at)atlassian(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5974: UNION construct type cast gives poor error message
Date: 2011-04-13 19:52:20
Message-ID: 4DA5B8A4020000250003C7A9@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
 
> The reason we haven't done it is that it looks like the SQL
> standard requires type resolution for set-ops to happen one pair
> of input relations at a time.
 
Well, it also requires that an unadorned quoted literal is of type
char(n).  This is inextricably tied in with the PostgreSQL deviation
from standard handling of literals so that user-defined types can be
more gracefully handled.
 
>From my perspective the "right" answer is to be able to resolve two
unknown types to unknown rather than text in a few places where we
are currently compelled to assign a concrete type.  This just seems
odd and wrong:
 
test=# select pg_typeof((select '1' limit '1'));
 pg_typeof
-----------
 unknown
(1 row)

test=# select pg_typeof((select '2' limit '1'));
 pg_typeof
-----------
 unknown
(1 row)

test=# select pg_typeof((select '1' union all select '2' limit
'1'));
 pg_typeof
-----------
 text
(1 row)
 
Likewise with the CASE predicate and it abbreviated forms (e.g.,
COALESCE).
 
I remember looking at this a couple years ago and finding that
making that work was more time than I could throw at it just then,
but I'm convinced that several warts on the type handling which
generate posts on this list now and again would best be dealt with
that way.
 
At least part of the previous discussion was on the thread which
starts here:
 
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00388.php
 
As I recall, one issue is that as the code is currently organized,
some of this type resolution would need to be deferred to execution
time.  :-(
 
-Kevin

In response to

Responses

pgsql-bugs by date

Next:From: ShianmiinDate: 2011-04-13 20:07:16
Subject: Re: [BUGS] PostgreSQL backend process high memory usage issue
Previous:From: Heikki LinnakangasDate: 2011-04-13 19:10:44
Subject: Re: 9.1 doesn't start when died mid-backup

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