Summary: changes needed in function defaults behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Summary: changes needed in function defaults behavior
Date: 2008-12-17 14:28:52
Message-ID: 28302.1229524132@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

So to summarize what I think we agreed to yesterday:

* CREATE OR REPLACE FUNCTION has to prevent reducing the pronargdefaults
value of an existing function (ie, you can add more defaults but not
remove any). This ensures a function that matched a given call before
will continue to do so.

* CREATE OR REPLACE FUNCTION also has to prevent a change in the actual
datatype of the default for any polymorphic parameter. This ensures
that we won't come to a different conclusion about the result type or
the coerced type of any non-defaulted parameter.

* Variadic parameters should be allowed to have defaults (where the
default would typically be an empty array of the right type, though
other possibilities are imaginable). Requiring the zero-element
case to be treated as a default makes the default and variadic features
act independently, and it avoids a problematic case for variadic
anyarray.

* Two functions that could match a given call after adding defaults
are considered ambiguous only if they would add the same number of
defaults; otherwise we prefer the one with fewer parameters. This
generalizes the rule that an exact match (no defaults) is preferred
over one that requires adding defaults.

* The parser should *not* add the values of the default expressions
into the parse tree, because that would lock down possibly-obsolete
values into stored views. Instead the same work has to be repeated
at plan time. (It's okay for the planner to do it since we already
have a mechanism to invalidate cached plans when the functions they
call are changed.) We are willing to tolerate some performance loss
in planning speed for this feature.

Barring objections I'll get started on making these changes.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-12-17 14:29:41 Re: notification payloads
Previous Message Bruce Momjian 2008-12-17 14:11:20 Re: [ADMIN] shared_buffers and shmmax