> > > I would like for you to also consider adding the following to gram.y for
> > > version 6.5:
> > > | NULL_P '=' a_expr
> > >     {       $$ = makeA_Expr(ISNULL, NULL, $3, NULL); }
> > > I know there was some discussion about this earlier including comments
> > > against this.  Access 97 is now generating the following statement and
> > > error...
> 
> I'm not certain that this patch should survive. There are at least two
> other places in the parser which should be modified for symmetry (the
> "b_expr" and the default expressions) and I recall that these lead to
> more shift/reduce conflicts. Remember that shift/reduce conflicts
> indicate that some portion of the parser logic can *never* be reached,
> which means that some feature (perhaps the new one, or perhaps an
> existing one) is disabled.


Yes, that is true.  There are several cases where we check just for =
NULL and not NULL = in the internals, not the grammar.

> 
> There is currently a single shift/reduce conflict in  gram.y, and I'm
> suprised to find that it is *not* due to the "NULL_P '=' a_expr" line.

Yep.  I got that working with precidence for NULL, I think.

> I'm planning on touching gram.y to hunt down the shift/reduce conflict
> (from previous work I think it in Stefan's "parens around selects"
> mods), and I'll look at the NULL_P issue again also.
> 
> I'll reiterate something which everyone probably knows: "where NULL =
> expr" is *not* standard SQL92, and any company selling products which
> implement this rather than the standard "where expr is NULL" should
> make your "don't buy" list, rather than your "only buy" list, which is
> what they are trying to force you to do :(

Yes, but some of the tools output that, and I think that was the
complaint.  I can go either way on this.

> 
>                             - Tom

Any chance of making your signature Thomas, to not confuse it with Tom
Lane?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 10 May 1999 15:01:30 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
NULL = col
> Yes, that is true.  There are several cases where we check just for =
> NULL and not NULL = in the internals, not the grammar.

That part is probably OK, since both statements are internalized to be
the same.

> > There is currently a single shift/reduce conflict in  gram.y, and I'm
> > suprised to find that it is *not* due to the "NULL_P '=' a_expr" line.
> Yep.  I got that working with precidence for NULL, I think.

Hmm.

> Any chance of making your signature Thomas, to not confuse it with Tom
> Lane?

I'm trying to, but it's *so* many letters to type...

                        - Tom^H^H^Hhomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 11 May 1999 03:23:34 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: NULL = col