On Fri, Aug 12, 2016 at 12:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Aug 12, 2016 at 9:40 AM, Greg Stark <st...@mit.edu> wrote: >>> I wonder whether it's really worth keeping postfix operators. They >>> seem to keep causing these kinds of headaches and I wonder how much >>> the grammar tables would be simplified by removing them. > >> I've wondered the same thing at other times. The only postfix >> operator we ship in core is numeric_fac, and frankly it doesn't seem >> worth it just for that. If we decided that factorial(n) was adequate >> notation for that case, and that we didn't care about any hypothetical >> user-defined postfix operators either, I think we simplify or improve >> a number of things. > > [ quick experiment... ] Simply removing the two postfix-operator > productions produces no meaningful savings (~0.5%), which is unsurprising > because after all they're just two more productions to Bison. It's > possible we could save more by simplifying the existing hacks elsewhere > in the grammar that were needed to work around ambiguities induced by > postfix operators. But that would take quite a bit of actual work, > and I suspect we'd end up with a similar result that the tables don't > actually get much smaller. You could argue for this on the grounds of > some reduced intellectual complexity in gram.y, and more forcefully on > the grounds of removing user surprise in cases like Jim's (especially if > you can find some other cases where it matters). But I doubt that we'd > get any kind of noticeable run-time or code-size win.
Half a percent for two productions is not bad, but I think the real win would be in removing ambiguity from the grammar. We get periodic complaints about the fact that things like "SELECT 3 cache" don't work because cache is an unreserved keyword, and postfix operators are one of the reasons why we can't do better: /* * We support omitting AS only for column labels that aren't * any known keyword. There is an ambiguity against postfix * operators: is "a ! b" an infix expression, or a postfix * expression and a column label? We prefer to resolve this * as an infix expression, which we accomplish by assigning * IDENT a precedence higher than POSTFIXOP. */ I think I experimented with this a while ago and found that even after removing postfix operators there was at least one other grammar problem that prevented us from accepting ColLabel there. I gave up and didn't dig further, but maybe we should. I sort of like the elegance of supporting user-defied prefix and postfix operators, but in practice this is a not-especially-infrequent problem for people migrating from other databases, a consideration that might be judged to outweigh that elegance. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers