From: Robert Haas on
On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> alvherre <alvherre(a)commandprompt.com> writes:
>> The problem with the => operator seems best resolved as not accepting
>> such an operator in a function parameter, which sucks but we don't seem
>> to have a choice.
>
> "Sucks" is not the word; "utterly unacceptable" is the word.  Having an
> expression mean different things depending on context is a recipe for
> unbelievable nightmares.  Can you imagine dealing with that in a query
> generator for example?  Or even ruleutils.c?
>
> If we go with the spec's syntax I think we'd have no realistic choice
> except to forbid => altogether as an operator name.  (And no, I'm not
> for that.)

I suppose the most painful thing about doing that is that it would
break hstore. Are there other commonly-used modules that rely on =>
as an operator name?

In spite of the difficulties, I'm reluctant to give up on it. I
always thought that the "AS" syntax was a crock and I'm not eager to
invent another crock to replace it. Being compatible with the SQL
standard and with Oracle is not to be taken lightly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on
On 27/05/10 03:57, Robert Haas wrote:
> Being compatible with the SQL
> standard and with Oracle is not to be taken lightly.

I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters. Can someone point me to the relevant
section of the standard?

As evidence to the contrary:
http://archives.postgresql.org/pgsql-hackers/2009-08/msg00558.php

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> If we go with the spec's syntax I think we'd have no realistic choice
>> except to forbid => altogether as an operator name. �(And no, I'm not
>> for that.)

> I suppose the most painful thing about doing that is that it would
> break hstore. Are there other commonly-used modules that rely on =>
> as an operator name?

There don't seem to be any other contrib modules that define => as an
operator name, but I'm not sure what's out there on pgfoundry or
elsewhere. The bigger issue to me is not so much hstore itself as that
this is an awfully attractive operator name for anything container-ish.
Wasn't the JSON-datatype proposal using => for an operator at one stage?
(The current wiki page for it doesn't seem to reflect any such idea,
though.) And I think I remember Oleg & Teodor proposing such an
operator in conjunction with some GIN-related idea or other.

> In spite of the difficulties, I'm reluctant to give up on it. I
> always thought that the "AS" syntax was a crock and I'm not eager to
> invent another crock to replace it. Being compatible with the SQL
> standard and with Oracle is not to be taken lightly.

Yeah, I know. Though this could end up being one of the bits of the
spec that we politely decline to follow, like upper-casing identifiers.
Still, it's a good idea to think again before we've set the release
in stone ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on
On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name.  (And no, I'm not
>>> for that.)
>
>> I suppose the most painful thing about doing that is that it would
>> break hstore.  Are there other commonly-used modules that rely on =>
>> as an operator name?
>
> There don't seem to be any other contrib modules that define => as an
> operator name, but I'm not sure what's out there on pgfoundry or
> elsewhere.  The bigger issue to me is not so much hstore itself as that
> this is an awfully attractive operator name for anything container-ish.
> Wasn't the JSON-datatype proposal using => for an operator at one stage?
> (The current wiki page for it doesn't seem to reflect any such idea,
> though.)  And I think I remember Oleg & Teodor proposing such an
> operator in conjunction with some GIN-related idea or other.
>
>> In spite of the difficulties, I'm reluctant to give up on it.  I
>> always thought that the "AS" syntax was a crock and I'm not eager to
>> invent another crock to replace it.  Being compatible with the SQL
>> standard and with Oracle is not to be taken lightly.
>
> Yeah, I know.  Though this could end up being one of the bits of the
> spec that we politely decline to follow, like upper-casing identifiers.
> Still, it's a good idea to think again before we've set the release
> in stone ...

Perhaps one idea would be to:

1. Invent a new crock for now.
2. Add a duplicate version of the hstore => operator with a different name.
3. Emit a warning whenever an operator called => is created.
4. Document that beginning in PG 9.1, we will no longer support => as
an operator name.

That's still going to cause a fair amount of pain, but certainly less
if we decide it now rather than later.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on
>>
>
> 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(a)postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers