On Tue, Dec 16, 2008 at 3:25 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers