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

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@commandprompt.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@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

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

alvherre <alvherre@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

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@gmail.com> writes:

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl@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

On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl@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

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

2010/5/27 Heikki Linnakangas <heikki.linnakangas@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

2010/5/27 Tom Lane <tgl@sss.pgh.pa.us>:

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl@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

2010/5/27 Robert Haas <robertmhaas@gmail.com>:

On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl@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

On 27/05/10 09:50, Pavel Stehule wrote:

2010/5/27 Heikki Linnakangas<heikki.linnakangas@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

At 2010-05-27 08:50:18 +0200, pavel.stehule@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

2010/5/27 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:

On 27/05/10 09:50, Pavel Stehule wrote:

2010/5/27 Heikki Linnakangas<heikki.linnakangas@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

2010/5/27 Abhijit Menon-Sen <ams@toroid.org>:

At 2010-05-27 08:50:18 +0200, pavel.stehule@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

On 27/05/10 10:16, Pavel Stehule wrote:

2010/5/27 Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>:

On 27/05/10 09:50, Pavel Stehule wrote:

2010/5/27 Heikki Linnakangas<heikki.linnakangas@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

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.