Re: Function call - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Function call
Date
Msg-id 25023.1075227225@sss.pgh.pa.us
Whole thread Raw
In response to Re: Function call  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Function call
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Dennis Bjorklund wrote:
>> Thinking more about it, I'm not sure if it really is an important
>> addition at all. I've got a number of requests for the feature. so
>> there are people that want it, that much I know.

> I like it very much, and I think mostly everyone else does, too.  It's 
> just a question of what syntax to use.

There are some pretty severe implementation problems that I haven't seen
mentioned yet.  In particular, how will you avoid individually trawling
through every function with a matching name to try to match up the
arguments?  The index on proargtypes won't help you if you don't know
what order the arguments are actually in.  And I think the heuristics in
func_select_candidate() that involve comparing matches at "the same
argument position" will break down completely.

(Adding default values would make overloaded functions an order of
magnitude slower yet, not to mention outright ambiguous.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: index scan with functional indexes
Next
From: Tom Lane
Date:
Subject: Re: Incorrect START TRANSACTION implementation