functional call named notation clashes with SQL feature
in [PgSql]
|
From: Joseph Adams on 4 Jun 2010 21:55 On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> If we go with the spec's syntax I think we'd have no realistic choice >>> except to forbid => altogether as an operator name. �(And no, I'm not >>> for that.) > >> I suppose the most painful thing about doing that is that it would >> break hstore. �Are there other commonly-used modules that rely on => >> as an operator name? > > There don't seem to be any other contrib modules that define => as an > operator name, but I'm not sure what's out there on pgfoundry or > elsewhere. �The bigger issue to me is not so much hstore itself as that > this is an awfully attractive operator name for anything container-ish. > Wasn't the JSON-datatype proposal using => for an operator at one stage? > (The current wiki page for it doesn't seem to reflect any such idea, > though.) �And I think I remember Oleg & Teodor proposing such an > operator in conjunction with some GIN-related idea or other. > >> In spite of the difficulties, I'm reluctant to give up on it. �I >> always thought that the "AS" syntax was a crock and I'm not eager to >> invent another crock to replace it. �Being compatible with the SQL >> standard and with Oracle is not to be taken lightly. > > Yeah, I know. �Though this could end up being one of the bits of the > spec that we politely decline to follow, like upper-casing identifiers. > Still, it's a good idea to think again before we've set the release > in stone ... > > � � � � � � � � � � � �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 > I didn't really consider using => for json because it would interfere with hstore (one of the signatures is text => text returns hstore, for instance). I am considering using -> as a json subscript operator (which is what hstore does) as it shouldn't interfere with hstore (as far as I know). Here's a thought: suppose we did use the foo (name => value) syntax for naming parameters. It could still be used in a very similar way for hstore: hstore(key1 => 'value1', key2 => 'value2') One advantage here is that => wouldn't be exclusive to hstore anymore. E.g.: json(key1 => 'value1', key2 => 'value2') However, note that the left hand of => is an identifier here, whereas the left hand of hstore's current => operator is either text, text[], or hstore. If I had to choose between => and := for parameter naming, I'd go with := because it seems more SQLish to me. I wonder if the foo (name : value) syntax would be possible/desirable. Or maybe foo ({name: value}) :-) Joey Adams -- 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: Greg Stark on 5 Jun 2010 10:32 On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > No, that really isn't going to work: how will the parser know that the > names are not meant to match to actual named parameters of the function? > You could possibly do it with a special case for hstore() in the > grammar, but we aren't going there, because it wouldn't be extensible. > 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. -- greg -- 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: Pavel Stehule on 5 Jun 2010 12:54 2010/6/5 Greg Stark <gsstark(a)mit.edu>: > On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> No, that really isn't going to work: how will the parser know that the >> names are not meant to match to actual named parameters of the function? >> You could possibly do it with a special case for hstore() in the >> grammar, but we aren't going there, because it wouldn't be extensible. >> > > 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. > I like this idea. Using a named expression for variadic parameter can be way. Maybe have to be explicitly enabled. Then we don't need special keyword or special syntax. like CREATE OR REPLACE FUNCTION hstore_constructor(VARIADIC params "anyelement"[]) AS $$ ... $$ STORE_PARAM_NAMES and maybe we can emulate old behave of hstore. Regards Pavel Stehule > -- > greg > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- 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: "David E. Wheeler" on 5 Jun 2010 13:08 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 -- 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:02
Joseph Adams <joeyadams3.14159(a)gmail.com> writes: > Here's a thought: suppose we did use the foo (name => value) syntax > for naming parameters. It could still be used in a very similar way > for hstore: > hstore(key1 => 'value1', key2 => 'value2') No, that really isn't going to work: how will the parser know that the names are not meant to match to actual named parameters of the function? You could possibly do it with a special case for hstore() in the grammar, but we aren't going there, because it wouldn't be extensible. The other variant with 'key1' => 'value1' isn't a lot better. Yes, we could make it work since it can't possibly be name => value, but it would be impossibly error-prone for people to use. The assumption that you can always replace a constant by a variable is very deeply wired into users' thinking, but doing so would make for a radical change in what the syntax meant. From a usability point of view, if we adopt the spec's syntax we have to stop allowing => for any other purpose. Period. 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 |