On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor <rod.tay...@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?
This would solve all of my conflicts correctly. I nearly always use RETURN QUERY with OUT parameters. An alternative would be the requirement to prefix out parameters with "out", "export", or something similar, so the plain non-prefixed name is never replaced. "b" in the below is the table. I hit this quite a bit since my historical table name might be "foo_bar_baz" which is the same as the most relevant name for the out parameter. I've debated renaming all of my tables t_* on more than one occasion as a workaround in applications which exclusively use functions to access/write data. create or replace function read_some_data_from_data_region(a integer, out b integer) as $$ begin SELECT col INTO out.b FROM b; return; end; $$ language plpgsql; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers