Re: functional call named notation clashes with SQL feature

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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