Dennis Bjorklund <db@zigo.dhs.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
http://www.postgresql.org/docs/7.4/static/typeconv-func.html
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
