Re: Out parameters handling
От | Robert Haas |
---|---|
Тема | Re: Out parameters handling |
Дата | |
Msg-id | 603c8f070903071354x102830efp8db68bcf05ade068@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Out parameters handling (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Out parameters handling
|
Список | pgsql-hackers |
On Sat, Mar 7, 2009 at 11:32 AM, 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? I think that would definitely be an improvement. Would that mean that in a query like the following: SELECT t.id FROM test t WHERE t.id = 17 ...it wouldn't consider replacing "t"? That all by itself would be an improvement... I actually feel like the best thing to do would be to error out if there's an ambiguous reference. If you write this: SELECT id FROM foo, bar WHERE foo.a = bar.a ...it will complain if both foo.id and bar.id are defined. So if I write: SELECT id FROM foo ...shouldn't it complain if both foo.id and <parameter namespace>.id are defined? ...Robert
В списке pgsql-hackers по дате отправления: