Re: functional call named notation clashes with SQL feature

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: alvherre <alvherre(at)commandprompt(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: functional call named notation clashes with SQL feature
Date: 2010-05-27 00:21:11
Message-ID: 5084.1274919671@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2010-05-27 00:25:05 Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT
Previous Message Andrew Dunstan 2010-05-27 00:20:53 Re: Distclean does not remove gram.c