From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Function call |
Date: | 2004-01-27 18:13:45 |
Message-ID: | 25023.1075227225@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-27 18:21:18 | Re: Incorrect START TRANSACTION implementation |
Previous Message | Dave Cramer | 2004-01-27 18:09:13 | Re: index scan with functional indexes |