Re: Summary: changes needed in function defaults behavior
От | Pavel Stehule |
---|---|
Тема | Re: Summary: changes needed in function defaults behavior |
Дата | |
Msg-id | 162867790812170641gfbb38d8ga7eb008c5fcc8971@mail.gmail.com обсуждение исходный текст |
Ответ на | Summary: changes needed in function defaults behavior (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2008/12/17 Tom Lane <tgl@sss.pgh.pa.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
В списке pgsql-hackers по дате отправления: