Dennis Bjorklund <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match