From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Jim(dot)Nasby(at)BlueTreble(dot)com |
Cc: | david(dot)g(dot)johnston(at)gmail(dot)com, 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-24 03:54:48 |
Message-ID: | 20150424.125448.105731176.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Hello,
At Thu, 23 Apr 2015 14:49:29 -0500, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> wrote in <55394CC9(dot)5050703(at)BlueTreble(dot)com>
> 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 guess so. It looks not intentional about this behavior at
all.
> 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.
That's what makes me unconfident. But if coercion is always made
by coerce_type and coercion is properly considered at all places
needs it, and this coercion steps is appropriate, we will see
nothing bad. I hope.
> 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).
Mmm.. It's a serious bug if explicit casts are ignored. If some
cast procedures does wrong, it should be fixed.
> 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.
Yeah, but it seems tough to do it throughly.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | pdrolet | 2015-04-24 10:10:06 | BUG #13143: Cannot stop and restart a streaming server with a replication slot |
Previous Message | Alvaro Herrera | 2015-04-24 01:59:05 | Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-24 04:22:46 | Re: forward vs backward slashes in msvc build code |
Previous Message | Amit Kapila | 2015-04-24 03:40:54 | Re: Reducing tuple overhead |