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