Hello,
At Thu, 23 Apr 2015 14:49:29 -0500, Jim Nasby <Jim.Nasby@BlueTreble.com> wrote in <55394CC9.5050703@BlueTreble.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