Re: functional call named notation clashes with SQL feature

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?

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

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 <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

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

alvherre <alvherre(at)commandprompt(dot)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

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> alvherre <alvherre(at)commandprompt(dot)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

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

>>
>
> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

2010/5/27 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

2010/5/27 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

2010/5/27 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

On 27/05/10 09:50, Pavel Stehule wrote:
> 2010/5/27 Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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

At 2010-05-27 08:50:18 +0200, pavel(dot)stehule(at)gmail(dot)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

2010/5/27 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> On 27/05/10 09:50, Pavel Stehule wrote:
>>
>> 2010/5/27 Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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
>

2010/5/27 Abhijit Menon-Sen <ams(at)toroid(dot)org>:
> At 2010-05-27 08:50:18 +0200, pavel(dot)stehule(at)gmail(dot)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
>

On 27/05/10 10:16, Pavel Stehule wrote:
> 2010/5/27 Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>:
>> On 27/05/10 09:50, Pavel Stehule wrote:
>>>
>>> 2010/5/27 Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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

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.

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

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> ::=
=>

2010/5/26 Peter Eisentraut <peter_e(at)gmx(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Andrew Dunstan <andrew(at)dunslane(dot)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

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

On Thu, May 27, 2010 at 1:27 PM, David E. Wheeler <david(at)kineticode(dot)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

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

On Thu, May 27, 2010 at 2:59 PM, David E. Wheeler <david(at)kineticode(dot)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

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);

?

Peter Eisentraut <peter_e(at)gmx(dot)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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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

2010/5/27 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

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 <david(at)kineticode(dot)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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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.

Andrew Dunstan <andrew(at)dunslane(dot)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

On 27/05/10 22:55, Tom Lane wrote:
> Peter Eisentraut<peter_e(at)gmx(dot)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

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Peter Eisentraut<peter_e(at)gmx(dot)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

2010/5/28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>>> Peter Eisentraut<peter_e(at)gmx(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>
>>> Peter Eisentraut<peter_e(at)gmx(dot)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

> 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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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

Andrew Dunstan <andrew(at)dunslane(dot)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

Josh Berkus <josh(at)agliodbs(dot)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

On Fri, May 28, 2010 at 10:08 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2010/5/28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>>>> Peter Eisentraut<peter_e(at)gmx(dot)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

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

2010/5/31 Bruce Momjian <bruce(at)momjian(dot)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  <bruce(at)momjian(dot)us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Bruce Momjian <bruce(at)momjian(dot)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

2010/5/31 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Bruce Momjian <bruce(at)momjian(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

Bruce Momjian <bruce(at)momjian(dot)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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

On Mon, May 31, 2010 at 3:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Greg Stark wrote:
> On Mon, May 31, 2010 at 3:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

Greg Stark <gsstark(at)mit(dot)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

2010/5/31 Bruce Momjian <bruce(at)momjian(dot)us>:
> Greg Stark wrote:
>> On Mon, May 31, 2010 at 3:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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  <bruce(at)momjian(dot)us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

2010/5/31 Bruce Momjian <bruce(at)momjian(dot)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  <bruce(at)momjian(dot)us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + None of us is going to be here forever. +
>
>

Pavel Stehule wrote:
> 2010/5/31 Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

2010/5/31 Bruce Momjian <bruce(at)momjian(dot)us>:
> Pavel Stehule wrote:
>> 2010/5/31 Bruce Momjian <bruce(at)momjian(dot)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  <bruce(at)momjian(dot)us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + None of us is going to be here forever. +
>
>

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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

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

"David E. Wheeler" <david(at)kineticode(dot)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

On Jun 1, 2010, at 0:23 , Tom Lane wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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

On Mon, May 31, 2010 at 9:24 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Jun 1, 2010, at 0:23 , Tom Lane wrote:
>> "David E. Wheeler" <david(at)kineticode(dot)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

On May 31, 2010, at 7:40 PM, Robert Haas wrote:

> I was going to propose ==> across the board.

What about -> ?

D

"David E. Wheeler" <david(at)kineticode(dot)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

Tom Lane wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

On Mon, May 31, 2010 at 11:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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

Bruce Momjian <bruce(at)momjian(dot)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

2010/6/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "David E. Wheeler" <david(at)kineticode(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

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.

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

Bruce Momjian <bruce(at)momjian(dot)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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)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

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

Bruce Momjian <bruce(at)momjian(dot)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

Bruce Momjian <bruce(at)momjian(dot)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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

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

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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

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

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

On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)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

On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)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.

Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)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

On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Greg Stark <gsstark(at)mit(dot)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

2010/6/5 Greg Stark <gsstark(at)mit(dot)edu>:
> On Sat, Jun 5, 2010 at 3:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:

> From a usability point of view, if we adopt the spec's syntax we have to
> stop allowing => for any other purpose. Period.

What if we added a new "dual" type and limited the => operator only to that type, being, essentially, a constructor. Then hstore and function call param processing could be rewritten to transform those types into key/value pairs.

So you'd call functions with:

foo( bar => 1, baz => 'this');

Actually, now that I think about it, the hstore => basically does this: it constructs an hstore from its two values. So why not basically move hstore into core and just use it for function arguments?

Crazy idea, I know, but thought I'd just throw it out there.

Best,

David

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