Re: functional call named notation clashes with SQL feature

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: functional call named notation clashes with SQL feature
Дата
Msg-id C31178C4-4DB5-44FE-BBF4-DFEE69E006CE@kineticode.com
обсуждение исходный текст
Ответ на Re: functional call named notation clashes with SQL feature  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: functional call named notation clashes with SQL feature  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:

> From a usability point of view, if we adopt the spec's syntax we have to
> stop allowing => for any other purpose.  Period.

What if we added a new "dual" type and limited the => operator only to that type, being, essentially, a constructor.
Thenhstore and function call param processing could be rewritten to transform those types into key/value pairs. 

So you'd call functions with:
foo( bar => 1, baz => 'this');

Actually, now that I think about it, the hstore => basically does this: it constructs an hstore from its two values. So
whynot basically move hstore into core and just use it for function arguments? 

Crazy idea, I know, but thought I'd just throw it out there.

Best,

David




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature