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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Jeff Wu" <jwu(at)atlassian(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5974: UNION construct type cast gives poor error message
Date: 2011-04-13 20:39:16
Message-ID: 11920.1302727156@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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.

Well, it's not so easy as that. Consider

select '1' union select '1 ';

How many rows does that produce? You cannot answer without imputing a
data type to the columns. "text" will give a different answer than
"integer" or "bpchar".

It's possible that we could make UNION ALL act differently from all
other set-operations, and refrain from resolving a type for the single
case of UNION ALL; but I can't say that I care for that idea, or see any
support for it in the standard. AFAICS the standard says that output
data types are to be resolved in the same way for all set operations.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2011-04-13 21:10:03 Re: BUG #5974: UNION construct type cast gives poor error message
Previous Message Shianmiin 2011-04-13 20:09:00 Re: [BUGS] PostgreSQL backend process high memory usage issue