I wrote:
Andrew Dunstan and...@dunslane.net writes:
If we do need a precedence setting for NULL_P, then I think it should
probably be on its own and not sharing one with IS.
Yeah, I was thinking that too. If we put %prec on the IS [NOT] NULL
productions then there is no need for NULL_P to
While looking at the grammar's operator-precedence declarations in
connection with a recent pgsql-docs question, it struck me that this
declaration is a foot-gun waiting to go off:
%nonassoc IS NULL_P TRUE_P FALSE_P UNKNOWN /* sets precedence for IS
NULL, etc */
The only terminal that we
On 05/04/2011 07:39 PM, Tom Lane wrote:
While looking at the grammar's operator-precedence declarations in
connection with a recent pgsql-docs question, it struck me that this
declaration is a foot-gun waiting to go off:
%nonassoc IS NULL_P TRUE_P FALSE_P UNKNOWN /* sets precedence for
Andrew Dunstan and...@dunslane.net writes:
On 05/04/2011 07:39 PM, Tom Lane wrote:
If you try the experiment, you find out that the first interpretation is
preferred by the current grammar:
ERROR: operator does not exist: integer %% unknown
Yeah, IIRC the default action for a shift/reduce
On Thu, May 5, 2011 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So I'd still like to get rid of the precedence markings for TRUE_P,
FALSE_P, and UNKNOWN, and will do so unless somebody has a really good
reason not to. (It looks like we could avoid marking ZONE, too.) But
I would be
Greg Stark gsst...@mit.edu writes:
Isn't there already some gadget which forces postfix operators to be
discouraged compared to some other interpretation in other cases?
Yeah. I'm not unhappy with the current grammar's behavior in this case.
What's bothering me is that the implementation seems
On Thu, May 5, 2011 at 4:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
Isn't there already some gadget which forces postfix operators to be
discouraged compared to some other interpretation in other cases?
Yeah. I'm not unhappy with the current grammar's
