From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: functional call named notation clashes with SQL feature |
Date: | 2010-06-05 20:32:49 |
Message-ID: | 4C0AB471.2020209@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David E. Wheeler wrote:
> 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.
>
I'm fairly strongly inclined to go with Tom's original dictum above.
Even if it's not strictly true, doing anything else is likely to be
rather fragile, ISTM.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2010-06-06 09:11:02 | Out of date docs: DISABLE/ENABLE TRIGGER |
Previous Message | David E. Wheeler | 2010-06-05 17:08:52 | Re: functional call named notation clashes with SQL feature |