| From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
|---|---|
| To: | pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: functional call named notation clashes with SQL feature |
| Date: | 2010-06-05 17:08:52 |
| Message-ID: | C31178C4-4DB5-44FE-BBF4-DFEE69E006CE@kineticode.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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. Then hstore 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 why not 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-06-05 20:32:49 | Re: functional call named notation clashes with SQL feature |
| Previous Message | Pavel Stehule | 2010-06-05 16:54:46 | Re: functional call named notation clashes with SQL feature |