On 4/23/15 5:07 AM, Kyotaro HORIGUCHI wrote:
This is because parsing of UNION immediately converts constants
of unknown type in the UNION's both arms to text so the top level
select won't be bothered by this problem. But the problematic
query doesn't have appropriate timing to do that until the
function I patched.
FWIW, I think that's more accidental than anything.
I'm no expert in our casting and type handling code but I spent a lot of
time stuck in it while working on the variant type, and it seems very
scattered. There's stuff in the actual casting code, there's some stuff
in other parts of parse/plan, there's stuff in individual types (array
and record at least).
Some stuff is handled by casting; some stuff is handled by mangling the
parse tree.
Something else I noticed is we're not consistent with handling typmod
either. I don't remember the exact example I found, but there's cases
involving casting of constants where we ignore it (I don't think it was
as simple as SELECT 1::int::variant(...), but it was something like that).
I don't know how much of this is just historical and how much is
intentional, but it'd be nice if we could consolidate it more.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
