Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)
| От | Darren Duncan |
|---|---|
| Тема | Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name) |
| Дата | |
| Msg-id | 4D8E54CE.1060006@darrenduncan.net обсуждение исходный текст |
| Ответ на | Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name) (Pavel Stehule <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
Pavel Stehule wrote: > sorry - I dislike this. The design is correct, but it is against to > SQL verbosity. A reader must to thinking about missing tablenames. I > dont't think so it is good solution, because it doesn't solve a > backing compatibility problem - somebody must to fix a function still, > and I think so it is much preferable to fix like: > > select (mytbl.mycol + myvar * myparam) as mynewcol from mytbl; > > your proposal saves a five chars, but it has a negative impacts on > readability - there should be more tables. > > There are no reason to introduce a new concepts - SQL knows a aliases. Well, going forward, I know I would much rather have to say "mytbl.mycol" than have to say "myfunc.myparam". And I certainly would want to expect that when one says "... as foo" that this "foo" is treated as a declaration unambiguously and is never substituted for some parameter or there be other grief as I seem to recall having in 8.4. -- Darren Duncan
В списке pgsql-hackers по дате отправления: