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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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