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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: WIP: Allow SQL-language functions to reference parameters by parameter name