Re: [BUGS] Failure to coerce unknown type to specific type

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: <pgsql(at)j-davis(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Failure to coerce unknown type to specific type
Date: 2015-04-23 19:49:29
Message-ID: 55394CC9.5050703@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2015-04-24 00:14:49 Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
Previous Message Heikki Linnakangas 2015-04-23 18:41:45 Re: BUG #13128: Postgres deadlock on startup failure when max_prepared_transactions is not sufficiently high.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-04-23 19:53:50 Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
Previous Message Robert Haas 2015-04-23 19:46:20 Re: tablespaces inside $PGDATA considered harmful