Re: Summary: changes needed in function defaults behavior - Mailing list pgsql-hackers
| From | Asko Oja |
|---|---|
| Subject | Re: Summary: changes needed in function defaults behavior |
| Date | |
| Msg-id | ecd779860812190013w218907f2x25425dfa01e1ad65@mail.gmail.com Whole thread Raw |
| In response to | Re: Summary: changes needed in function defaults behavior (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-hackers |
I would agree with making it stricter. It would force people to do less stupid things.
Our main use case for default parameter will be getting rid of all the old versions of functions with shorter parameter lists by just creating new versions of old functions with additional default parameters.
We don't use views much but all the fuss and restrictions that surround them gives me a feeling that there might be something to be improved in how they are implemented/hacked into the PostgreSQL.
What might be the use case for
foo(f1 int)
foo(f1 int, f2 int = 42)
foo(f1 int, f2 int = 42, f3 int = 43)
?
When i have function in database
foo(f1 int)
and do create or replace
foo(f1 int, f2 int = 42)
I would expect foo to get replaced.
Current implementation seems to make us go through drop create sequence.
regards,
Asko
PS. Any chance for lifting the restriction for changing function return type without dropping the function.
Our main use case for default parameter will be getting rid of all the old versions of functions with shorter parameter lists by just creating new versions of old functions with additional default parameters.
We don't use views much but all the fuss and restrictions that surround them gives me a feeling that there might be something to be improved in how they are implemented/hacked into the PostgreSQL.
What might be the use case for
foo(f1 int)
foo(f1 int, f2 int = 42)
foo(f1 int, f2 int = 42, f3 int = 43)
?
When i have function in database
foo(f1 int)
and do create or replace
foo(f1 int, f2 int = 42)
I would expect foo to get replaced.
Current implementation seems to make us go through drop create sequence.
regards,
Asko
PS. Any chance for lifting the restriction for changing function return type without dropping the function.
On Thu, Dec 18, 2008 at 12:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:Experimenting with the revised code, I found a curious case that might
> * 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.
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) ...
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
pgsql-hackers by date: