On Tue, Dec 16, 2008 at 3:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Does anyone think this is either unsurprising or desirable?
That's horrible.
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default values,
we should actually create M entries in pg_proc: one for each possible
number of arguments from N-M up through N. The one with N arguments
would be the main entry, and the rest would be dependent entries that
would get dropped if the main entry were dropped (similar to the way
sequences for serial columns depend on the parent table). If one of
the dependent entries conflicted with an existing entry, then CREATE
FUNCTION would simply fail.
I think this would kill all of the problems reported thus far at one
blow. There wouldn't be any need for code to resolve ambiguous
function calls because there wouldn't be any ambiguous function calls,
or at least no more than what already exists in 8.3. The problem you
report here would go away because the view definition would match one
of the dummy entries. Removing a necessary default value would remove
that dummy entry, which would be caught by the existing dependency
stuff. Changing a default would amount to changing the definition of
a dummy entry as if by CREATE OR REPLACE FUNCTION, which would work
just as expected.
...Robert