functional call named notation clashes with SQL feature
in [PgSql]
|
From: Andrew Dunstan on 5 Jun 2010 16:32 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 5 Jun 2010 10:59
Greg Stark <gsstark(a)mit.edu> writes: > I wonder if we could offer something like VARIADIC but allows > arbitrarily named parameters which get passed in a hstore-like hash > instead of an array. Just thinking aloud here. I haven't thought about > what this would mean in the function call api. Yeah, with an extra keyword to disambiguate, you could make that work. Not sure if there are enough use-cases to justify it though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |