Skip site navigation (1) Skip section navigation (2)

Re: Function call

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Function call
Date: 2004-01-28 17:03:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:
> Now, the above is just my plan before coding and before understanding 
> everything. It might work and it might not. So far I've got no reason to 
> thing that it wont work,

Before you start writing anything, I suggest you read
I can see at least three assumptions in there that will be broken by
allowing different candidate functions to have arguments matched in
different orders.  That's not even counting the questions about whether
we should allow the names of parameters to affect which functions are
considered to be potential candidates.

>> What might be the best compromise is to treat parameter names as
>> documentation *only*, that is, we insist that the parameters have to
>> appear in the declared order in any case.

> That would suck big time.

I don't think you should reject it out of hand.  It's simple and
understandable, and it is guaranteed not to break any existing code
when the programmer simply adds names to the parameter declarations
of a function without changing any call sites.  If the presence of
parameter names changes the ambiguity resolution rules at all, I'm
doubtful that we could guarantee not to break things.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Dennis BjorklundDate: 2004-01-28 17:16:11
Subject: Re: Function call
Previous:From: Greg StarkDate: 2004-01-28 15:09:34
Subject: Re: Question about indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group