Re: proposal: new polymorphic types - commontype and commontypearray - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: new polymorphic types - commontype and commontypearray
Date
Msg-id CAFj8pRDmeOoTFZ-OCQizm_AJ2XiWXh0J_19K-zADxHHXfZSyFA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: new polymorphic types - commontype and commontypearray  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: new polymorphic types - commontype and commontypearray  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


st 18. 3. 2020 v 17:14 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
So ... there is a definitional question here that doesn't seem to have
been mentioned anywhere in the thread.  For the traditional polymorphic
types, we insist that at least one non-unknown input be supplied, thus
you get

regression=# create function foo(anyelement, anyelement) returns bool
regression-# language sql as 'select $1 = $2';
CREATE FUNCTION

regression=# select foo('a', 'b');
ERROR:  could not determine polymorphic type because input has type unknown

regression=# select foo('a', 'b'::text);
 foo
-----
 f
(1 row)

As this patch stands, the ANYCOMPATIBLE types also require that:

regression=# create function foo2(anycompatible, anycompatible) returns bool
language sql as 'select $1 = $2';
CREATE FUNCTION

regression=# select foo2('a', 'b');
ERROR:  could not determine polymorphic common type because input has type unknown

However, it seems to me that this is inconsistent with the definition,
namely that we resolve the common type the same way select_common_type()
does, because select_common_type() will choose TEXT when given all-unknown
inputs.  So shouldn't we choose TEXT here?
Admittedly, the fact that select_common_type() falls back to TEXT is a
bit of a wart, so maybe we don't want to propagate it here.  But if we
don't, we'll have to document the selection rule as almost but not
quite like what it says in section 10.5.  That seems confusing.

Documentation issues aside, I'm not quite sure whether this behavior
would be more or less preferable in practice than sticking with the
existing behavior.  It seems like it'd be convenient in some cases
but possibly allow mistakes to go undetected in others.

Thoughts?

It is difficult question. What I know, this issue is less than we can expect, because almost all functions are called with typed parameters (columns, variables).

the fallback to text is enticement but maybe better is consistency with other polymorphic types.

Maybe users can implement own fallback behave with next custom function

create function foo2(text, text) returns bool
language sql as 'select $1 = $2';

Regards

Pavel



                        regards, tom lane

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Autovacuum on partitioned table (autoanalyze)
Next
From: Fujii Masao
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side