Re: [HACKERS] Two questions about Postgres parser
On 2/27/17 10:37 AM, Tom Lane wrote: 2. Implicit user defined type casts are not applied for COALESCE operator: That has nothing to do with whether the cast is user-defined. It has to do with not wanting to automatically unify types across type-category boundaries (in this case, numeric vs. composite categories). That's per step 4 here: https://www.postgresql.org/docs/devel/static/typeconv-union-case.html and it's not an easy thing to get rid of because if you're considering more than one type category then the heuristic about preferring "preferred types" breaks down --- how do you know which category's preferred type to prefer? FWIW, while working on a variant type I wished there was a way to preempt built-in type resolution when dealing with a particular type. I was specifically interested in function calls, which IIRC is handled by a single function and a helper. Exporting those two and providing a hook would have done the trick in my case. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Two questions about Postgres parser
Konstantin Knizhnik writes: > 1. Moving-aggregate implementation should return the same type as plain > implementation. Yes, in most cases it is hard to find arguments why them > should return different types. But it is not true for vectorized > operations... I can't see a reason why we would want to go there. And if your design for vectorized operations requires different user-visible semantics than for the same operation non-vectorized, don't you have a problem anyway? > 2. Implicit user defined type casts are not applied for COALESCE operator: That has nothing to do with whether the cast is user-defined. It has to do with not wanting to automatically unify types across type-category boundaries (in this case, numeric vs. composite categories). That's per step 4 here: https://www.postgresql.org/docs/devel/static/typeconv-union-case.html and it's not an easy thing to get rid of because if you're considering more than one type category then the heuristic about preferring "preferred types" breaks down --- how do you know which category's preferred type to prefer? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
