Re: Function call

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

In response to

Responses

Browse pgsql-hackers by date

  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