Re: [HACKERS] functional call named notation clashes with SQL feature
Joseph Adams joeyadams3.14...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane t...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Greg Stark gsst...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/6/5 Greg Stark gsst...@mit.edu: On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane t...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@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@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams joeyadams3.14...@gmail.com wrote:
If I had to choose between = and := for parameter naming, I'd go with
:= because it seems more SQLish to me.
On second thought, = might actually be a very intuitive syntax for
defining dictionary types like hstore and json, since it matches PHP's
associative array syntax, as in:
hstore('key1' = 'value1', 'key2' = 'value2') -- hypothetical SQL
array('key1' = 'value1', 'key2' = 'value2') // PHP
That way, when people see =, they can think dictionary whether
they're in PHP or SQL.
Note that this is a bit different than what I suggested earlier:
hstore(key1 = 'value1', key2 = 'value2')
Identifier names were used instead of literal names, which conflicts
with the other approach. Also, the other approach is more flexible,
as the user can generate names with expressions at runtime.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Peter Eisentraut wrote: On m?n, 2010-05-31 at 18:23 -0400, Tom Lane wrote: My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. Given that Oracle and DB2 already support that syntax in released products, and I'm not even a member of any relevant body, that seems pretty much impossible. With beta2 being wrapped today, we are going to be releasing ':=' as our method for function parameter assignment, but also with the likely outcome that we are going to need to support '=' very soon. Are we sure we want hstore compatibility to drive this decision? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian br...@momjian.us writes: Are we sure we want hstore compatibility to drive this decision? hstore is what it is, and has been that way for a long time. We can't just ignore it. And I don't think breaking it (and probably other code) on zero notice is an acceptable outcome. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Are we sure we want hstore compatibility to drive this decision? hstore is what it is, and has been that way for a long time. We can't just ignore it. And I don't think breaking it (and probably other code) on zero notice is an acceptable outcome. Well, it seems we are going to be stuck supporting = because it is hard to argue that the SQL standards committee should adopt := instead of = because of hstore. ;-) I hate eventually having two documented ways of doing something, but it appears by releasing := we are doing exactly that. Is telling hstore users they have to change = to something else such a large major version incompatibility that it is worth supporting and documenting two syntaxes for parameter assignment? It is that calculus that has me questioning our approach. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Are we sure we want hstore compatibility to drive this decision? hstore is what it is, and has been that way for a long time. We can't just ignore it. And I don't think breaking it (and probably other code) on zero notice is an acceptable outcome. Well, it seems we are going to be stuck supporting = because it is hard to argue that the SQL standards committee should adopt := instead of = because of hstore. ;-) I hate eventually having two documented ways of doing something, but it appears by releasing := we are doing exactly that. Is telling hstore users they have to change = to something else such a large major version incompatibility that it is worth supporting and documenting two syntaxes for parameter assignment? It is that calculus that has me questioning our approach. I don't mind supporting := and = as much as I mind supporting only :=, and I think that's the other reasonable alternative. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Are we sure we want hstore compatibility to drive this decision? hstore is what it is, and has been that way for a long time. We can't just ignore it. And I don't think breaking it (and probably other code) on zero notice is an acceptable outcome. Well, it seems we are going to be stuck supporting = because it is hard to argue that the SQL standards committee should adopt := instead of = because of hstore. ;-) I hate eventually having two documented ways of doing something, but it appears by releasing := we are doing exactly that. Is telling hstore users they have to change = to something else such a large major version incompatibility that it is worth supporting and documenting two syntaxes for parameter assignment? It is that calculus that has me questioning our approach. Thinking some more, what is the value of keeping = in hstore for 9.0? Perhaps we could create a script they could run on 8.4 that would add support for the new hstore operator to replace =, and then they can upgrade to 9.0 when they are ready. I see only three mentions of = in hstore.sql. Do we really want to keep the := baggage forever just for hstore? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian br...@momjian.us writes: Is telling hstore users they have to change = to something else such a large major version incompatibility that it is worth supporting and documenting two syntaxes for parameter assignment? It is that calculus that has me questioning our approach. Well it's not only hstore. Anyone can CREATE OPERATOR = on any released version of PostgreSQL currently. I don't think we can deprecate it on short notice, so we'll have := in 9.0, and maybe a deprecation notice for =. Now that it's pretty clear from Peter that the standard is not going to change its choice here, I'll vote adding a WARNING each time an operator called = is created, so that we get a chance to move later on. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian br...@momjian.us writes: Thinking some more, what is the value of keeping = in hstore for 9.0? Backwards compatibility. You have not made any argument today that we have not been over many times before. I do not have time to argue about this today --- I have to go fix max_standby_delay. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Jun 3, 2010, at 8:54 AM, Tom Lane wrote: Thinking some more, what is the value of keeping = in hstore for 9.0? Backwards compatibility. You have not made any argument today that we have not been over many times before. I do not have time to argue about this today --- I have to go fix max_standby_delay. I'm sure there's a lot of code using = in the wild. We can't just drop them without a deprecation cycle. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote: Now that it's pretty clear from Peter that the standard is not going to change its choice here, I'll vote adding a WARNING each time an operator called = is created, so that we get a chance to move later on. Should support for == be added to hstore for 9.0? So both = and == will work? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Thinking some more, what is the value of keeping = in hstore for 9.0? Backwards compatibility. You have not made any argument today that we have not been over many times before. I do not have time to argue about this today --- I have to go fix max_standby_delay. Agreed. I am just making sure we are going in the right direction. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
David E. Wheeler wrote: On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote: Now that it's pretty clear from Peter that the standard is not going to change its choice here, I'll vote adding a WARNING each time an operator called = is created, so that we get a chance to move later on. Should support for == be added to hstore for 9.0? So both = and == will work? I have added the idea to the 9.0 open items wiki: http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Code -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 5/27/2010 11:52 PM, Andrew Dunstan wrote: Bruce Momjian wrote: Peter Eisentraut wrote: On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); One concern I have is that in PL/pgSQL, := and = behave the same, while in SQL, they would not. That might cause confusion. That is a sad wart that we should never have done, IMNSHO (it was before my time or I would have objected ;-) ). But beyond that, = is an operator in SQL and := is never an operator, IIRC. As far as I can tell, this was already in the code when Bruce moved it into core as -r1.1 on my behalf (before I had commit privileges). I do not recall if the = as alternative to := was my idea or not. But I'm willing to take the blame for it because it dates back to a time where convenience seemed important. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Jan Wieck wrote: That is a sad wart that we should never have done, IMNSHO (it was before my time or I would have objected ;-) ). But beyond that, = is an operator in SQL and := is never an operator, IIRC. As far as I can tell, this was already in the code when Bruce moved it into core as -r1.1 on my behalf (before I had commit privileges). I do not recall if the = as alternative to := was my idea or not. But I'm willing to take the blame for it because it dates back to a time where convenience seemed important. I forgive you ;=) If my worst sin were only this bad I'd be truly happy. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On mån, 2010-05-31 at 18:23 -0400, Tom Lane wrote: My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. Given that Oracle and DB2 already support that syntax in released products, and I'm not even a member of any relevant body, that seems pretty much impossible. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: So as far as I can tell, no one is opposed to replacing expr AS name with name := expr in the named-parameter syntax. Obviously we had better get this done before beta2. Is anyone actually working on the code/docs changes? If not, I'll pick it up. If we eventually are going to want to support the ANSI standard = syntax, I am thinking we should just do it now. The larger question is what justification do we have of not supporting =. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/31 Bruce Momjian br...@momjian.us: Tom Lane wrote: So as far as I can tell, no one is opposed to replacing expr AS name with name := expr in the named-parameter syntax. Obviously we had better get this done before beta2. Is anyone actually working on the code/docs changes? If not, I'll pick it up. If we eventually are going to want to support the ANSI standard = syntax, I am thinking we should just do it now. The larger question is what justification do we have of not supporting =. I am for ANSI stanadard. I afraid so we can do nothing now. First we have to implement substitution of = operator in hstore module. Second we have to mark this operator as deprecated. Maybe we can do it in 9.1 with integration of hstore to core. I would to see any hash table support in core. It can be significant help for PLpgSQL coders. What more - it can work nice with proposed JSON support. Regards Pavel -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: So as far as I can tell, no one is opposed to replacing expr AS name with name := expr in the named-parameter syntax. Obviously we had better get this done before beta2. Is anyone actually working on the code/docs changes? If not, I'll pick it up. If we eventually are going to want to support the ANSI standard = syntax, I am thinking we should just do it now. The larger question is what justification do we have of not supporting =. Not breaking hstore, as well as any third-party modules that might be using that operator name. Did you not absorb any of the discussion so far? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/31 Tom Lane t...@sss.pgh.pa.us: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: So as far as I can tell, no one is opposed to replacing expr AS name with name := expr in the named-parameter syntax. Obviously we had better get this done before beta2. Is anyone actually working on the code/docs changes? If not, I'll pick it up. If we eventually are going to want to support the ANSI standard = syntax, I am thinking we should just do it now. The larger question is what justification do we have of not supporting =. Not breaking hstore, as well as any third-party modules that might be using that operator name. Did you not absorb any of the discussion so far? can we search thise applications? I know only about hstore module. We can ask people who use it in own applications. But every major version of PostgreSQL can breaks compatibility - like 9.0 with variable names in plpgsql. Regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: So as far as I can tell, no one is opposed to replacing expr AS name with name := expr in the named-parameter syntax. Obviously we had better get this done before beta2. Is anyone actually working on the code/docs changes? If not, I'll pick it up. If we eventually are going to want to support the ANSI standard = syntax, I am thinking we should just do it now. The larger question is what justification do we have of not supporting =. Not breaking hstore, as well as any third-party modules that might be using that operator name. Did you not absorb any of the discussion so far? Yes, but if we are going to have to honor = eventually, shouldn't we just do it now? Supporting := and = seems confusing. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian br...@momjian.us writes: Yes, but if we are going to have to honor = eventually, shouldn't we just do it now? Supporting := and = seems confusing. Personally, I haven't accepted the if part of that, therefore I feel no need to argue over the then. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Yes, but if we are going to have to honor = eventually, shouldn't we just do it now? Supporting := and = seems confusing. Personally, I haven't accepted the if part of that, therefore I feel no need to argue over the then. Right, I am asking about the if part. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Not breaking hstore, as well as any third-party modules that might be using that operator name. Did you not absorb any of the discussion so far? In fairness most of the discussion about breaking hstore was prior to our learning that the sql committee had gone so far into the weeds. If = is sql standard syntax then perhaps that changes the calculus. It's no longer a matter of supporting some oracle-specific syntax that diverges from sqlish syntax and conflicts with our syntax. Instead it's a question of our operator syntax conflicting with the sql standard. Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Greg Stark wrote: On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Not breaking hstore, as well as any third-party modules that might be using that operator name. ?Did you not absorb any of the discussion so far? In fairness most of the discussion about breaking hstore was prior to our learning that the sql committee had gone so far into the weeds. If = is sql standard syntax then perhaps that changes the calculus. It's no longer a matter of supporting some oracle-specific syntax that diverges from sqlish syntax and conflicts with our syntax. Instead it's a question of our operator syntax conflicting with the sql standard. Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? Tangentially, I think the SQL committee chose = because the value, then variable, ordering is so unintuitive, and I think they wanted that ordering because most function calls use values so they wanted the variable at the end. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Greg Stark gsst...@mit.edu writes: If = is sql standard syntax then perhaps that changes the calculus. Well, it *isn't* standard, yet at least. All we have is a report of the current wording of a draft that's at least a year from release. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/31 Bruce Momjian br...@momjian.us: Greg Stark wrote: On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Not breaking hstore, as well as any third-party modules that might be using that operator name. ?Did you not absorb any of the discussion so far? In fairness most of the discussion about breaking hstore was prior to our learning that the sql committee had gone so far into the weeds. If = is sql standard syntax then perhaps that changes the calculus. It's no longer a matter of supporting some oracle-specific syntax that diverges from sqlish syntax and conflicts with our syntax. Instead it's a question of our operator syntax conflicting with the sql standard. Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? Tangentially, I think the SQL committee chose = because the value, then variable, ordering is so unintuitive, and I think they wanted that ordering because most function calls use values so they wanted the variable at the end. maybe, maybe not. Maybe just adopt Oracle's syntax - nothing more, nothing less - like like some others. Regards Pavel -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Yes, but if we are going to have to honor = eventually, shouldn't we just do it now? Supporting := and = seems confusing. Personally, I haven't accepted the if part of that, therefore I feel no need to argue over the then. OK, but if that's going to influence the decision, let's debate it. I think we should aim to comply with the spec, and incidentally be compatible with Oracle too. = is used by a number of other languages, for this or a similar purpose, so it would feel a bit more intuitive and familiar to some people. I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of = as an operator now, and definitely remove its use in hstore either now or in 9.1. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Pavel Stehule wrote: Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? Tangentially, I think the SQL committee chose = because the value, then variable, ordering is so unintuitive, and I think they wanted that ordering because most function calls use values so they wanted the variable at the end. maybe, maybe not. Maybe just adopt Oracle's syntax - nothing more, nothing less - like like some others. Yea, definitely they were copying Oracle. My point is that the odd ordering does make sense, and the use of an arrow-like operator also makes sense because of the odd ordering. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/31 Bruce Momjian br...@momjian.us: Pavel Stehule wrote: Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? Tangentially, I think the SQL committee chose = because the value, then variable, ordering is so unintuitive, and I think they wanted that ordering because most function calls use values so they wanted the variable at the end. maybe, maybe not. Maybe just adopt Oracle's syntax - nothing more, nothing less - like like some others. Yea, definitely they were copying Oracle. My point is that the odd ordering does make sense, and the use of an arrow-like operator also makes sense because of the odd ordering. What I know - this feature is supported only by Oracle and MSSQL now. MSSQL syntax isn't available, because expected @ before variables. So there is available only Oracle's syntax. It is some like industrial standard. Pavel -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Pavel Stehule wrote: 2010/5/31 Bruce Momjian br...@momjian.us: Pavel Stehule wrote: Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? Tangentially, I think the SQL committee chose = because the value, then variable, ordering is so unintuitive, and I think they wanted that ordering because most function calls use values so they wanted the variable at the end. maybe, maybe not. Maybe just adopt Oracle's syntax - nothing more, nothing less - like like some others. Yea, definitely they were copying Oracle. ?My point is that the odd ordering does make sense, and the use of an arrow-like operator also makes sense because of the odd ordering. What I know - this feature is supported only by Oracle and MSSQL now. MSSQL syntax isn't available, because expected @ before variables. So there is available only Oracle's syntax. It is some like industrial standard. MSSQL? Are you sure? This is the example posted in this thread: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 and it more matches our := syntax than = in its argument ordering. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/31 Bruce Momjian br...@momjian.us: Pavel Stehule wrote: 2010/5/31 Bruce Momjian br...@momjian.us: Pavel Stehule wrote: Part of the earlier discussion was about how = was a tempting operator name and other users may well have chosen it precisely because it's so evocative. But we don't actually have any evidence of that. Does anyone have any experience seeing = operators in the wild? Tangentially, I think the SQL committee chose = because the value, then variable, ordering is so unintuitive, and I think they wanted that ordering because most function calls use values so they wanted the variable at the end. maybe, maybe not. Maybe just adopt Oracle's syntax - nothing more, nothing less - like like some others. Yea, definitely they were copying Oracle. ?My point is that the odd ordering does make sense, and the use of an arrow-like operator also makes sense because of the odd ordering. What I know - this feature is supported only by Oracle and MSSQL now. MSSQL syntax isn't available, because expected @ before variables. So there is available only Oracle's syntax. It is some like industrial standard. MSSQL? Are you sure? This is the example posted in this thread: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 and it more matches our := syntax than = in its argument ordering. it's not important in this discussion. Important is using some usual symbol '=' or special symbol '='. Our syntax is probably only one possible solution in this moment (there are minimum controversy), bud semantic isn't best. Using same operator as assign statement uses can be messy. I don't know what is a true - you have to ask of ADA designers. Regards Pavel -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian wrote: MSSQL? Are you sure? This is the example posted in this thread: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 and it more matches our := syntax than = in its argument ordering. I think you are seriously confused, or else you are seriously confusing me. The = proposal is to have the ordering param_name = passed_value, just as Oracle has, just as MSSQL has @param_name = passed_value, and just as the := proposal would have param_name := passed_value. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Andrew Dunstan wrote: Bruce Momjian wrote: MSSQL? Are you sure? This is the example posted in this thread: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 and it more matches our := syntax than = in its argument ordering. I think you are seriously confused, or else you are seriously confusing me. The = proposal is to have the ordering param_name = passed_value, just as Oracle has, just as MSSQL has @param_name = passed_value, and just as the := proposal would have param_name := passed_value. You are right; I am seriously confused. I thought it was value = variable. I was wrong. I now see the Oracle syntax matches the Perl hash assignment syntax. The = operator is helpful in documenting the correspondence between keys and values in hashes, and other paired elements in lists. %hash = ( $key = $value ); login( $username = $password ); -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Pavel Stehule pavel.steh...@gmail.com writes: it's not important in this discussion. Important is using some usual symbol '=' or special symbol '='. Our syntax is probably only one possible solution in this moment (there are minimum controversy), bud semantic isn't best. Using same operator as assign statement uses can be messy. I don't know what is a true - you have to ask of ADA designers. Well you assign a value to a named parameter, so I don't see the point. Now SELECT myfunc(a := 1, b = 2); is about fine, the only point is that the = operator looks good for associative things such as hstore, so chances that it has been used are not so low. I guess we could choose to go with := for 9.1 and revisit the = situation after the SQL standard has settled on the new version. Maybe this move would even have some impact now that we have a voice over there. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of = as an operator now, and definitely remove its use in hstore either now or in 9.1. +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of = as an operator now, and definitely remove its use in hstore either now or in 9.1. My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. hstore's use of = is pretty well embedded already; waiting another release or two before breaking things is not going to make it significantly more painful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Jun 1, 2010, at 0:23 , Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of = as an operator now, and definitely remove its use in hstore either now or in 9.1. My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. hstore's use of = is pretty well embedded already; waiting another release or two before breaking things is not going to make it significantly more painful. There might be some value in providing an alternative operator though, even if there is no definitive plan to deprecate '='. hstore gained quite a few new features in 9.0 that might attract new users. If there is even a slight chance that '=' will be deprecated during the next few releases, it'd be nice to save these users the hassle of migration... For text = text and text[] = text[] I'd propose '||' as an alternative, since they both combine their arguments, kind of a like a concatenation. For hstore = text[] I'd suggest '' since the result's set of keys is the intersection of both argument's key-sets. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Mon, May 31, 2010 at 9:24 PM, Florian Pflug f...@phlo.org wrote: On Jun 1, 2010, at 0:23 , Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of = as an operator now, and definitely remove its use in hstore either now or in 9.1. My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. hstore's use of = is pretty well embedded already; waiting another release or two before breaking things is not going to make it significantly more painful. There might be some value in providing an alternative operator though, even if there is no definitive plan to deprecate '='. hstore gained quite a few new features in 9.0 that might attract new users. If there is even a slight chance that '=' will be deprecated during the next few releases, it'd be nice to save these users the hassle of migration... For text = text and text[] = text[] I'd propose '||' as an alternative, since they both combine their arguments, kind of a like a concatenation. For hstore = text[] I'd suggest '' since the result's set of keys is the intersection of both argument's key-sets. I was going to propose == across the board. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On May 31, 2010, at 7:40 PM, Robert Haas wrote: I was going to propose == across the board. What about - ? D -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 7:40 PM, Robert Haas wrote: I was going to propose == across the board. What about - ? hstore already uses that for something else. Robert's idea isn't a bad one if we're forced to rename the operator. I'd still like to know exactly how hard the concrete has set on the SQL spec draft, first. (Peter?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 7:40 PM, Robert Haas wrote: I was going to propose == across the board. What about - ? hstore already uses that for something else. Robert's idea isn't a bad one if we're forced to rename the operator. I'd still like to know exactly how hard the concrete has set on the SQL spec draft, first. (Peter?) I don't know, but based on the fact it matches Oracle, I think it is pretty well set by now. If we can't come up with a good syntax (and there isn't an SQL standard for it), we often review how Oracle or other databases handle such cases, and my guess is that the SQL committee does the same thing. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Mon, May 31, 2010 at 11:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 7:40 PM, Robert Haas wrote: I was going to propose == across the board. What about - ? hstore already uses that for something else. Robert's idea isn't a bad one if we're forced to rename the operator. I'd still like to know exactly how hard the concrete has set on the SQL spec draft, first. (Peter?) Given the way hstore uses -, another reasonable choice might be -- That way we'd have - and -- instead of - and == -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: I'd still like to know exactly how hard the concrete has set on the SQL spec draft, first. (Peter?) I don't know, but based on the fact it matches Oracle, I think it is pretty well set by now. Eh? The SQL committee has a very long track record of blowing off any and all Oracle syntaxes. If we can point to good reasons to adjust their syntax, they might still listen. Or at least I'd like to hear the opinion of our man on the ground before assuming they won't. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/6/1 Tom Lane t...@sss.pgh.pa.us: David E. Wheeler da...@kineticode.com writes: On May 31, 2010, at 7:40 PM, Robert Haas wrote: I was going to propose == across the board. What about - ? hstore already uses that for something else. Robert's idea isn't a bad one if we're forced to rename the operator. I'd still like to know exactly how hard the concrete has set on the SQL spec draft, first. (Peter?) I agree with Tom - we are not hurry. Creating some synonym operator for hstore like == can be a good idea. regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
So as far as I can tell, no one is opposed to replacing expr AS name with name := expr in the named-parameter syntax. Obviously we had better get this done before beta2. Is anyone actually working on the code/docs changes? If not, I'll pick it up. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 27/05/10 22:55, Tom Lane wrote: Peter Eisentrautpete...@gmx.net writes: How about select myfunc(a := 7, b := 6); ? Hey, that's a thought. We couldn't have used that notation before because we didn't have := as a separate token, but since I hacked that in for plpgsql's benefit, I think it might be an easy fix. It'd be nice that it puts the argument name first like the spec syntax, too. If we go with that, should we make some preparations to allow = in the future? Like provide an alternative operator name for hstore's =, and add a note somewhere in the docs to discourage other modules from using =. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Peter Eisentrautpete...@gmx.net writes: How about select myfunc(a := 7, b := 6); If we go with that, should we make some preparations to allow = in the future? Like provide an alternative operator name for hstore's =, and add a note somewhere in the docs to discourage other modules from using =. I'd vote no. We're intentionally choosing to deviate from a very poor choice of notation. Maybe Peter can interest the committee in allowing := as an alternate notation, instead. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/28 Tom Lane t...@sss.pgh.pa.us: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Peter Eisentrautpete...@gmx.net writes: How about select myfunc(a := 7, b := 6); If we go with that, should we make some preparations to allow = in the future? Like provide an alternative operator name for hstore's =, and add a note somewhere in the docs to discourage other modules from using =. I'd vote no. We're intentionally choosing to deviate from a very poor choice of notation. Maybe Peter can interest the committee in allowing := as an alternate notation, instead. -1 I prefer a standard. And again - it isn't poor syntax - ADA, Perl use it, It can be a funny if ANSI SQL committee change some design from Oracle's proposal to PostgreSQL's proposal. Regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Peter Eisentrautpete...@gmx.net writes: How about select myfunc(a := 7, b := 6); If we go with that, should we make some preparations to allow = in the future? Like provide an alternative operator name for hstore's =, and add a note somewhere in the docs to discourage other modules from using =. I'd vote no. We're intentionally choosing to deviate from a very poor choice of notation. Maybe Peter can interest the committee in allowing := as an alternate notation, instead. What's poor about it? It probably comes from PLSQL which in turn got it from Ada, so they aren't just making this up. I agree it's inconvenient for us, but that's a different issue. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
What's poor about it? It probably comes from PLSQL which in turn got it from Ada, so they aren't just making this up. I agree it's inconvenient for us, but that's a different issue. Further, the ( parameter := value ) notation is not only consistent with what is used inside pl/pgsql, it's also more consistent than AS with SQL Server's named parameter notation, which is: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 Since former SQL Server / Sybase apps are the most likely to use named parameter notation in PostgreSQL, having a syntax which could be ported using only sed would be nice. Relevant to the whole discussion, though ... is the conflicting SQL standard syntax something we're every likely to implement? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Josh Berkus wrote: Since former SQL Server / Sybase apps are the most likely to use named parameter notation in PostgreSQL, having a syntax which could be ported using only sed would be nice. Relevant to the whole discussion, though ... is the conflicting SQL standard syntax something we're every likely to implement? Not sure, but I assume people could be using the AS syntax in other databases (for the inheritance usage) and then trying to use it in our database. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian wrote: Josh Berkus wrote: Since former SQL Server / Sybase apps are the most likely to use named parameter notation in PostgreSQL, having a syntax which could be ported using only sed would be nice. Relevant to the whole discussion, though ... is the conflicting SQL standard syntax something we're every likely to implement? Not sure, but I assume people could be using the AS syntax in other databases (for the inheritance usage) and then trying to use it in our database. Yeah. Whether or not we ever implement it really doesn't matter, IMO. We should not be in the business of taking an SQL standard piece of syntax and using it for some other purpose. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 28/05/10 19:19, Josh Berkus wrote: ( parameter := value ) notation is not only consistent with what is used inside pl/pgsql, it's also more consistent than AS with SQL Server's named parameter notation, which is: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 Since former SQL Server / Sybase apps are the most likely to use named parameter notation in PostgreSQL, having a syntax which could be ported using only sed would be nice. Once you solve the problem of finding the '='s in the source, replacing them is exactly the same effort regardless of what you replace them with. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Josh Berkus j...@agliodbs.com writes: Since former SQL Server / Sybase apps are the most likely to use named parameter notation in PostgreSQL, having a syntax which could be ported using only sed would be nice. I fear you're vastly overestimating the ability of sed to distinguish between = used in this way and = used in any other way. Still, putting the parameter name on the left is clearly both more natural and more like every other product. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Andrew Dunstan and...@dunslane.net writes: Yeah. Whether or not we ever implement it really doesn't matter, IMO. We should not be in the business of taking an SQL standard piece of syntax and using it for some other purpose. Evidently the 201x SQL standard has blindsided us twice: first by defining a syntax for named parameters that wasn't like ours, and second by defining a syntax for something else that conflicted with ours. I agree that the AS approach is pretty untenable given that double whammy, and we'd better get rid of it. (Hopefully Peter will be able to keep us better apprised of things in the future.) It seems that we're agreed on trying to use := instead, and the only debate is about whether to deprecate use of = as an operator. But anything that we might do about the latter would reach no farther than the documentation in 9.0 anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Fri, May 28, 2010 at 10:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/5/28 Tom Lane t...@sss.pgh.pa.us: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Peter Eisentrautpete...@gmx.net writes: How about select myfunc(a := 7, b := 6); If we go with that, should we make some preparations to allow = in the future? Like provide an alternative operator name for hstore's =, and add a note somewhere in the docs to discourage other modules from using =. I'd vote no. We're intentionally choosing to deviate from a very poor choice of notation. Maybe Peter can interest the committee in allowing := as an alternate notation, instead. -1 I prefer a standard. And again - it isn't poor syntax - ADA, Perl use it, It can be a funny if ANSI SQL committee change some design from Oracle's proposal to PostgreSQL's proposal. I agree. It's good syntax. I think we should try hard to adopt it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 28/05/10 19:19, Josh Berkus wrote: EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 Once you solve the problem of finding the '='s in the source, replacing them is exactly the same effort regardless of what you replace them with. I guess it would be a choice of target between 'GXKP' AS ItemCode, 5 AS PriceLevel and ItemCode := 'GXKP', PriceLevel := 5 By the way, as it seems we're voting, I much prefer := than either the AS and = variant, and I'm not keen on seeing us deprecate the operator. Further, as said Andrew, keeping AS conflicting with the standard with no hysterical raisin to do so would be a bad move IMHO. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for this is 'paramname = value', but I think that has problems because of our possibly use of = as an operator - otherwise that would be by far the best way to go. What is advice of FOR instead AS? it is exactly same. Regards Pavel cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/27 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: On 27/05/10 02:09, alvherre wrote: Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for this is 'paramname = value', but I think that has problems because of our possibly use of = as an operator - otherwise that would be by far the best way to go. I think we were refraining from = because the standard didn't specify this back then -- AFAIU this was introduced very recently. But now that it does, and that the syntax we're implementing conflicts with a different feature, it seems wise to use the standard-mandated syntax. The problem with the = operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Perhaps we could allow = to resolve as the operator for the case the user really needs to use it; or a schema-qualified operator. AFAIU, the standard doesn't say anything about named parameters. Oracle uses =, but as you said, that's ambiguous with the = operator. +1 for FOR. I don't see any advantage of FOR. We can change ir to support new standard or don't change it. Pavel -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/27 Tom Lane t...@sss.pgh.pa.us: Robert Haas robertmh...@gmail.com writes: On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@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 ... we have a last minutes for decision. any other change will need years - like 'standard strings'. I agree so it's not good time for change. But this change is a few lines in parser. Regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/27 Robert Haas robertmh...@gmail.com: On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@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 ... Perhaps one idea would be to: 1. Invent a new crock for now. 2. Add a duplicate version of the hstore = operator with a different name. 3. Emit a warning whenever an operator called = is created. 4. Document that beginning in PG 9.1, we will no longer support = as an operator name. +1 Pavel That's still going to cause a fair amount of pain, but certainly less if we decide it now rather than later. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 27/05/10 09:50, Pavel Stehule wrote: 2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com: AFAIU, the standard doesn't say anything about named parameters. Oracle uses =, but as you said, that's ambiguous with the = operator. +1 for FOR. I don't see any advantage of FOR. Any advantage over AS? It doesn't clash with the foo AS bar syntax that the standard is using for something completely different, as Peter pointed out in the original post. We can change ir to support new standard or don't change it. What new standard? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote: I don't see any advantage of FOR. We can change ir to support new standard or don't change it. Adopting FOR would mean we don't use AS in a way that conflicts with the standard. That's its only advantage. But I agree with you, I don't think it's worth inventing a new non-standard wart for this case. I don't really like the idea of getting rid of = as an operator either; I'm torn between staying true to the standard and politely looking the other way as Tom suggested we might end up doing. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/27 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: On 27/05/10 09:50, Pavel Stehule wrote: 2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com: AFAIU, the standard doesn't say anything about named parameters. Oracle uses =, but as you said, that's ambiguous with the = operator. +1 for FOR. I don't see any advantage of FOR. Any advantage over AS? It doesn't clash with the foo AS bar syntax that the standard is using for something completely different, as Peter pointed out in the original post. No, standard knows AS in different context. In param list standard doesn't use keyword AS. We can change ir to support new standard or don't change it. What new standard? ANSI SQL 2011 Pavel -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/27 Abhijit Menon-Sen a...@toroid.org: At 2010-05-27 08:50:18 +0200, pavel.steh...@gmail.com wrote: I don't see any advantage of FOR. We can change ir to support new standard or don't change it. Adopting FOR would mean we don't use AS in a way that conflicts with the standard. That's its only advantage. But I agree with you, I don't think it's worth inventing a new non-standard wart for this case. current using AS isn't in conflict with standard .. look to standard, please. Pavel I don't really like the idea of getting rid of = as an operator either; I'm torn between staying true to the standard and politely looking the other way as Tom suggested we might end up doing. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 27/05/10 10:16, Pavel Stehule wrote: 2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com: On 27/05/10 09:50, Pavel Stehule wrote: 2010/5/27 Heikki Linnakangasheikki.linnakan...@enterprisedb.com: AFAIU, the standard doesn't say anything about named parameters. Oracle uses =, but as you said, that's ambiguous with the =operator. +1 for FOR. I don't see any advantage of FOR. Any advantage over AS? It doesn't clash with the foo AS bar syntax that the standard is using for something completely different, as Peter pointed out in the original post. No, standard knows AS in different context. In param list standard doesn't use keyword AS. As Peter pointed out in the original post, according to the standard function(foo AS bar) means something else than what we have now. Please re-read the original post. We can change ir to support new standard or don't change it. What new standard? ANSI SQL 2011 Oh, does that have something to say about named parameters? Is the draft publicly available somewhere? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote: On 27/05/10 03:57, Robert Haas wrote: Being compatible with the SQL standard and with Oracle is not to be taken lightly. I seem to be alone believing that the SQL standard doesn't say anything about named function parameters. Can someone point me to the relevant section of the standard? It will be in SQL:2011. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 27/05/10 10:49, Peter Eisentraut wrote: On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote: On 27/05/10 03:57, Robert Haas wrote: Being compatible with the SQL standard and with Oracle is not to be taken lightly. I seem to be alone believing that the SQL standard doesn't say anything about named function parameters. Can someone point me to the relevant section of the standard? It will be in SQL:2011. Does it mandate = ? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On tor, 2010-05-27 at 10:51 +0300, Heikki Linnakangas wrote:
On 27/05/10 10:49, Peter Eisentraut wrote:
On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote:
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters. Can someone point me to the relevant
section of the standard?
It will be in SQL:2011.
Does it mandate = ?
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::= left paren [ SQL argument [ { comma SQL
argument }... ] ] right paren
SQL argument ::= value expression
| generalized expression
| target specification
| contextually typed value specification
| named argument specification
generalized expression ::= value expression AS path-resolved
user-defined type name
named argument specification ::= SQL parameter name named argument
assignment token named argument SQL argument
named argument SQL argument ::= value expression
| target specification
| contextually typed value specification
named argument assignment token ::=
=
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/26 Peter Eisentraut pete...@gmx.net:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::= left paren [ SQL argument [ { comma SQL
argument }... ] ] right paren
SQL argument ::= value expression
| generalized expression
| target specification
generalized expression ::= value expression AS path-resolved
user-defined type name
In systems that have inheritance of composite types, this is used to
specify which type the value is supposed to be interpreted as (for
example, to treat the value as a supertype).
can it be used (in ANSI SQL semantic) as cast?
like SELECT foo(10.33 AS int)
Seems kind of bad to overload this with something completely different.
What should we do?
Is ANSI SQL consistent in this syntax? SQL/XML use AS in different meaning.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Andrew Dunstan and...@dunslane.net writes: Peter Eisentraut wrote: In systems that have inheritance of composite types, this is used to specify which type the value is supposed to be interpreted as (for example, to treat the value as a supertype). Why don't they just use CAST() syntax for that, instead of adding this unnecessary syntax wart? If their complaint is that CAST() is too much typing, perhaps they could adopt :: cast notation ;-) I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On May 27, 2010, at 9:59 AM, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about ISPARAMVALUEFOR? That shouldn't conflict with anything. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler da...@kineticode.com wrote: On May 27, 2010, at 9:59 AM, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about ISPARAMVALUEFOR? That shouldn't conflict with anything. Or we could use the Finnish word epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty sure is not currently used in our grammar. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On May 27, 2010, at 11:55 AM, Robert Haas wrote: Or we could use the Finnish word epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty sure is not currently used in our grammar. I thought that was an Icelandic volcano. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Thu, May 27, 2010 at 2:59 PM, David E. Wheeler da...@kineticode.com wrote: On May 27, 2010, at 11:55 AM, Robert Haas wrote: Or we could use the Finnish word epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty sure is not currently used in our grammar. I thought that was an Icelandic volcano. No, that's Eyjafjallajökull. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); ? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Peter Eisentraut pete...@gmx.net writes: On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); ? Hey, that's a thought. We couldn't have used that notation before because we didn't have := as a separate token, but since I hacked that in for plpgsql's benefit, I think it might be an easy fix. It'd be nice that it puts the argument name first like the spec syntax, too. Question #1: is the SQL committee likely to standardize that out from under us, too? Question #2: will ecpg have a problem with this? Or psql for that matter (can you have a psql variable named '=')? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
* Tom Lane (t...@sss.pgh.pa.us) wrote: Peter Eisentraut pete...@gmx.net writes: select myfunc(a := 7, b := 6); Kinda like it myself. Question #1: is the SQL committee likely to standardize that out from under us, too? Couldn't say on that one. Question #2: will ecpg have a problem with this? Or psql for that matter (can you have a psql variable named '=')? psql doesn't like it, for what it's worth: postgres=# \set = hi \set: error Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] functional call named notation clashes with SQL feature
2010/5/27 Tom Lane t...@sss.pgh.pa.us: Peter Eisentraut pete...@gmx.net writes: On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); ? Hey, that's a thought. We couldn't have used that notation before because we didn't have := as a separate token, but since I hacked that in for plpgsql's benefit, I think it might be an easy fix. It'd be nice that it puts the argument name first like the spec syntax, too. I can live with it. Regards Pavel Question #1: is the SQL committee likely to standardize that out from under us, too? Question #2: will ecpg have a problem with this? Or psql for that matter (can you have a psql variable named '=')? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Thu, May 27, 2010 at 02:55:54PM -0400, Robert Haas wrote: On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler da...@kineticode.com wrote: On May 27, 2010, at 9:59 AM, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about ISPARAMVALUEFOR? That shouldn't conflict with anything. Or we could use the Finnish word epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty sure is not currently used in our grammar. We could use the Turkish muvaffakiyetsizleştiricileştiriveremeyebileceklerimizdenmişsinizcesine, which I'm pretty sure isn't either :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Peter Eisentraut wrote: On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); One concern I have is that in PL/pgSQL, := and = behave the same, while in SQL, they would not. That might cause confusion. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Bruce Momjian wrote: Peter Eisentraut wrote: On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); One concern I have is that in PL/pgSQL, := and = behave the same, while in SQL, they would not. That might cause confusion. That is a sad wart that we should never have done, IMNSHO (it was before my time or I would have objected ;-) ). But beyond that, = is an operator in SQL and := is never an operator, IIRC. cheers andrew I doubt there will be much confusion. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Andrew Dunstan and...@dunslane.net writes: Bruce Momjian wrote: One concern I have is that in PL/pgSQL, := and = behave the same, while in SQL, they would not. That might cause confusion. I doubt there will be much confusion. I agree. Bruce is ignoring the fact that they are *not* interchangeable even in plpgsql, except in the one context of the assignment operator. If you try to use := in a SQL construct it won't work, eg if (a := b) then ... if (a = b) then ... have never been equivalent. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Peter Eisentraut wrote:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::= left paren [ SQL argument [ { comma SQL
argument }... ] ] right paren
SQL argument ::= value expression
| generalized expression
| target specification
generalized expression ::= value expression AS path-resolved
user-defined type name
In systems that have inheritance of composite types, this is used to
specify which type the value is supposed to be interpreted as (for
example, to treat the value as a supertype).
Seems kind of bad to overload this with something completely different.
What should we do?
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname = value', but I think that has
problems because of our possibly use of = as an operator - otherwise
that would be by far the best way to go.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for this is 'paramname = value', but I think that has problems because of our possibly use of = as an operator - otherwise that would be by far the best way to go. I think we were refraining from = because the standard didn't specify this back then -- AFAIU this was introduced very recently. But now that it does, and that the syntax we're implementing conflicts with a different feature, it seems wise to use the standard-mandated syntax. The problem with the = operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Perhaps we could allow = to resolve as the operator for the case the user really needs to use it; or a schema-qualified operator. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On May 26, 2010, at 4:09 PM, alvherre wrote: The problem with the = operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Perhaps we could allow = to resolve as the operator for the case the user really needs to use it; or a schema-qualified operator. I think requiring schema-qualification is an acceptable compromise. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 27/05/10 02:09, alvherre wrote: Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010: I think we should fix it now. Quick thought: maybe we could use FOR instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's mechanism for this is 'paramname = value', but I think that has problems because of our possibly use of = as an operator - otherwise that would be by far the best way to go. I think we were refraining from = because the standard didn't specify this back then -- AFAIU this was introduced very recently. But now that it does, and that the syntax we're implementing conflicts with a different feature, it seems wise to use the standard-mandated syntax. The problem with the = operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Perhaps we could allow = to resolve as the operator for the case the user really needs to use it; or a schema-qualified operator. AFAIU, the standard doesn't say anything about named parameters. Oracle uses =, but as you said, that's ambiguous with the = operator. +1 for FOR. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
alvherre alvhe...@commandprompt.com writes: The problem with the = operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Sucks is not the word; utterly unacceptable is the word. Having an expression mean different things depending on context is a recipe for unbelievable nightmares. Can you imagine dealing with that in a query generator for example? Or even ruleutils.c? 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.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: alvherre alvhe...@commandprompt.com writes: The problem with the = operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Sucks is not the word; utterly unacceptable is the word. Having an expression mean different things depending on context is a recipe for unbelievable nightmares. Can you imagine dealing with that in a query generator for example? Or even ruleutils.c? 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? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On 27/05/10 03:57, Robert Haas wrote: Being compatible with the SQL standard and with Oracle is not to be taken lightly. I seem to be alone believing that the SQL standard doesn't say anything about named function parameters. Can someone point me to the relevant section of the standard? As evidence to the contrary: http://archives.postgresql.org/pgsql-hackers/2009-08/msg00558.php -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Robert Haas robertmh...@gmail.com writes: On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@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 ... Perhaps one idea would be to: 1. Invent a new crock for now. 2. Add a duplicate version of the hstore = operator with a different name. 3. Emit a warning whenever an operator called = is created. 4. Document that beginning in PG 9.1, we will no longer support = as an operator name. That's still going to cause a fair amount of pain, but certainly less if we decide it now rather than later. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
