Re: factorial function/phase out postfix operators? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: factorial function/phase out postfix operators?
Date
Msg-id 31945.1589902330@sss.pgh.pa.us
Whole thread Raw
In response to Re: factorial function/phase out postfix operators?  (Vik Fearing <vik@postgresfriends.org>)
Responses Re: factorial function/phase out postfix operators?
List pgsql-hackers
Vik Fearing <vik@postgresfriends.org> writes:
> I'm -1 on keeping ! around as a hard-coded postfix operator.

Before we go much further on this, we should have some proof
that there's actually material benefit to be gained.  I spent some
time just now trying to relax the AS restriction by ripping out
postfix ops, and the results were not too promising.  Indeed the
postfix-ops problem goes away, but then you find out that SQL's
random syntax choices for type names become the stumbling block.
An example here is that given

    SELECT 'foo'::character varying

it's not clear if "varying" is supposed to be part of the type name or a
column label.  It looks to me like we'd have to increase the reserved-ness
of VARYING, PRECISION, and about half a dozen currently-unreserved
keywords involved in INTERVAL syntax, including such popular column names
as "month", "day", and "year".

Plus I got conflicts on WITHIN, GROUP, and FILTER from ordered-set
aggregate syntax; those are currently unreserved keywords, but they
can't be allowed as AS-less column labels.

We could possibly minimize the damage by inventing another keyword
classification besides the four we have now.  Or maybe we should
think harder about using more lookahead between the lexer and grammar.
But this is going to be a lot more ticklish than I would've hoped,
and possibly not cost-free, so we might well end up never pulling
the trigger on such a change.

So right at the moment I'm agreeing with Stephen's nearby opinion:
let's not deprecate these until we've got a patch that gets some
concrete benefit from removing them.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Trouble with hashagg spill I/O pattern and costing
Next
From: Tom Lane
Date:
Subject: Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION