Hello, At Thu, 23 Apr 2015 14:49:29 -0500, Jim Nasby <jim.na...@bluetreble.com> wrote in <55394cc9.5050...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
