2008/12/17 Tom Lane <tgl@sss.pgh.pa.us>:
> I wrote:
>> * 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.
>
> Experimenting with the revised code, I found a curious case that might
> be worth worrying about. Consider the example that started all this:
>
> create function foo(f1 int, f2 int = 42, f3 int = 43) ...
> create view v1 as select foo(11);
>
> The patch I've got correctly reverse-lists v1 as "select foo(11)".
> Now suppose we add
>
> create function foo(f1 int, f2 int = 42) ...
>
> or even
>
> create function foo(f1 int) ...
do you remember on request for using "default" keyword in funccall?
This should be solution. In view, you don't store select foo(11), but
you have to store select foo(11, default, default).
regards
Pavel Stehule
>
> The view is still gonna reverse-list as "select foo(11)" --- in fact,
> we really haven't got much choice about that. However, if dumped and
> reloaded along with one of these shorter-argument-list functions, the
> view will be reconstituted as a reference to the shorter function instead
> of the original 3-argument function.
>
> I'm not sure how critical this is, since you'd have to be pretty dumb to
> put together a set of functions like this that didn't work compatibly.
> Still, this is the first instance I know of in which dump/reload isn't
> going to be guaranteed to match the same function as was being called
> in the dumped database.
>
> If we think this is critical enough to be worth sacrificing something
> for, what I'd suggest is that we abandon the concept that shorter
> argument lists are allowed to win over longer ones. This would mean
> that
>
> foo(f1)
> foo(f1 int, f2 int = 42)
> foo(f1 int, f2 int = 42, f3 int = 43)
>
> would all be considered equally good matches for a call foo(11)
> and so you'd get an "ambiguous function" failure. While that doesn't
> prevent you getting into this sort of trouble, what it would do is
> ensure that the dump reload gives an error instead of silently picking
> the wrong function. Also, you'd most likely have gotten a few failures
> and thus been shown the error of your ways before you dumped the old
> DB at all.
>
> Thoughts?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
