Re: functional call named notation clashes with SQL feature

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

In response to

Browse pgsql-hackers by date

  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