Gregory Stark <st...@enterprisedb.com> writes:
> So it's not like any use case for default polymorphic arguments is going to be
> especially compelling either. But I don't see any reason it'll be any less
> useful for polymorphic arguments than any other type.
Well, the reason it seems funny to me is that the point of a polymorphic
argument is to be datatype-agnostic, and as soon as you put in a default
value of a particular type you're letting go of that principle.
The only case I can imagine being actually useful is where the default
is an untyped null, and you have a non-defaultable anyelement argument
that drives determination of what the defaulted one is, ie something
like
create function array2 (f1 anyelement, f2 anyelement = null)
returns anyarray
as 'select array[$1,$2]' language sql;
Although this seems well-defined in principle, I'm not sure if it
actually works with the current patch; and it'd be even trickier
if we try to put in some code that says "the default's type can't
change". A null constant has the same type as an unmarked string
literal (namely UNKNOWN) but IIRC they don't really behave the same
for type resolution purposes.
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
