Re: [HACKERS] Two questions about Postgres parser

[Jim Nasby]

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

[Tom Lane]

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

[HACKERS] Two questions about Postgres parser

[Konstantin Knizhnik]

Hi hackers,

Working on vectorized extension for Postgres (VOPS) I faced with two 
things in Postgres compiler which break my expectations and force me to 
abandon my original implementation plan. I wonder if it is really 
principle and correct that:


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...


2. Implicit user defined type casts are not applied for COALESCE operator:

create  type complex as (x float8, y float8);
create function float2complex(x float8) returns complex as $$ 
declare complex c; begin c.x := x; x.y = 0; return c; $$ language 
plpgsql strict immutable;
create cast (float8 as complex) with function float2complex(float8) 
as implicit;

create table foo(c complex);
select coalesce(c, 0.0) from foo;
ERROR:  COALESCE types complex and numeric cannot be matched
LINE 1: select coalesce(c, 0.0) from foo;

select coalesce(c, 0.0::float8) from foo;
ERROR:  COALESCE types complex and double precision cannot be matched
LINE 1: select coalesce(c, 0.0::float8) from foo;

select coalesce(c, 0.0::float8::complex) from foo;
 coalesce
--
(0 rows)

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers