I spent part of today looking at Gevik Babakhani's patch to let SQL-language functions refer to their parameters by name instead of just as $n. It's not ready to go yet but there are interesting definitional issues here, especially when you look ahead to using the same mechanism for resolving references to plpgsql parameters and local variables, as we've discussed previously: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00169.php
The first question is: what precedence should parameter lookup have relative to other possible ways to resolve an ambiguous name, ie, at what point do we give the callback a chance? In particular, should this occur before or after trying to resolve the name using an implicit RTE? Given that we've deprecated implicit RTEs, I think there's a good argument to be made for trying that last. The other thing that I'm thinking about is that if we change plpgsql to use this method then it will start resolving ambiguous names as query columns rather than local variables, when it has always done the opposite in the past. Based on all the complaints we've heard, this is probably the better definition, but surely it's going to break a few peoples' code in subtle ways. Is it important to provide a compatibility mode? If so, it seems the way to make that happen would be to give the callback hook two chances, once before we've tried for query-local names and once after. We'd need an extra argument in its signature so it'd know which call this is. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers