On 3/7/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor <rod.taylor@gmail.com> wrote:
> >> It wouldn't be so bad if you could assign internal and external column names.
>
> > This is a good point. Uglifying the parameter names is sort of OK for
> > input parameters, but is much more annoying for output parameters.
>
> How much of this pain would go away if we changed over to the arguably
> correct (as in Or*cle does it that way) scoping for names, wherein the
> parser first tries to match a name against column names of tables of the
> current SQL statement, and only failing that looks to see if they are
> plpgsql variables?
It would decrease the frequency of problems, but the problems that
will stay will be more obscure than before - currently you can guess
how the query will be parsed by just looking at function code, but
with oracle style parsing you need to know the table definitions also.
So my vote would go to some sort of alias or record variable
that contains either all arguments (so we can get rid of i_ prefixes)
or only out/inout variables.
This should be optional and user-chooseable at function start, so it can
be tied with local coding style. This seems to fit better to SQL style
of using table or column aliases to make name resolution clear.
I don't have clear idea of syntax for that, some variants:
DECLARE args ALIAS FOR IN|OUT|INOUT ARGS; args PREFIX FOR ARGS|OUTARGS|INARGS; ARGALIAS ret; RENAME funcname TO foo;
The PREFIX seems best of those as it also hints that the args will not be
available in plain form. Not sure what is the good way to specify the
IN|OUT|INOUT.
I'm not against the Oracle-style parsing, if the prefix solution is voted
down, it will be the next best thing. But my problem with it is that it
will make me actually less confident than current solution that
I really understand what a piece of SQL will actually end up doing.
Also it will introduce new ways to silent breakdowns: what if someone
adds new column to table with same name as function argument?
Btw - the prefix and the Oracle-style parsing are actually orthogonal
to each other so we could also have both.
--
marko