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