Summary: changes needed in function defaults behavior
От | Tom Lane |
---|---|
Тема | Summary: changes needed in function defaults behavior |
Дата | |
Msg-id | 28302.1229524132@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Summary: changes needed in function defaults behavior
Re: Summary: changes needed in function defaults behavior Re: Summary: changes needed in function defaults behavior |
Список | 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
В списке pgsql-hackers по дате отправления: