Re: Another issue in default-values patch: defaults expanded too soon

Gregory Stark <stark(at)enterprisedb(dot)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