Re: Summary: changes needed in function defaults behavior

2008/12/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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
>

it's look well

regards
Pavel Stehule

> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>