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

And while we're on the subject ... as the patch stands, it lets you
provide defaults for polymorphic parameters, as in

regression=# create function eq (f1 anyelement, f2 anyelement default 42) returns bool as 'select $1 = $2' language
sql;
CREATE FUNCTION
regression=# select eq(now(),now());eq 
----t
(1 row)

regression=# select eq(now());      
ERROR:  arguments declared "anyelement" are not all alike
DETAIL:  timestamp with time zone versus integer
regression=# select eq(11,12);eq 
----f
(1 row)

regression=# select eq(11);   eq 
----f
(1 row)

regression=# select eq(42);eq 
----t
(1 row)

The reason this is pretty wacko is that changing the default can change the
set of calls the function can match:

regression=# create or replace function eq (f1 anyelement, f2 anyelement default now()) returns bool as 'select $1 =
$2'language sql;
 
CREATE FUNCTION
regression=# select eq(now());      eq 
----t
(1 row)

regression=# select eq(42);
ERROR:  arguments declared "anyelement" are not all alike
DETAIL:  integer versus timestamp with time zone

In fact, it's worse than that: changing the default can change the
resolved output type of the function.

regression=# create function dupl (f1 anyelement default 42) returns anyelement                         
as 'select $1' language sql;
CREATE FUNCTION
regression=# select dupl();dupl 
------  42
(1 row)

regression=# create or replace function dupl (f1 anyelement default now()) returns anyelement
as 'select $1' language sql;
CREATE FUNCTION
regression=# select dupl();            dupl              
-------------------------------2008-12-16 17:39:41.418412-05
(1 row)

Isn't *that* special.  Needless to say, this would utterly break any
view or rule referencing the function.

I'm inclined to think we should forbid defaults for polymorphic
parameters, and wondered if anyone can come up with an actually useful
use-case that'd require it.  If we were going to allow it, we'd at least
have to restrict things enough so that the resolved output type couldn't
change.

(The reason I stumbled across this was that the current behavior is an
artifact of inserting the default expressions at parse time; in fact,
before resolving polymorphic types.  It would get very much more painful
to support any sort of behavior along this line if we don't do that.)
        regards, tom lane