RE: [HACKERS] NULL = col - Mailing list pgsql-hackers

I realize that supporting Access97 is going to be a pain and somewhat
undesirable, but I think that there are a lot of people like me who choose
Access97 because it seemed to be the best tool for the job.  I am not overly
satisfied with Access97 but it gets the job done.  Now, I would like to use
a real database and I don't want to invest any more $ in Microsoft, so I
choose Postgres.  I don't what to have to rewrite my entire front end, only
the back end.  I have not yet found a tool to replace Access97 as a front
end.  I am considering TK but creating and printing reports is very limited
and would take too long for me to migrate all of my reports to tk.  This
said, I would really appreciate it if PostgreSQL would support Access97 as a
front end.  I am sure many will follow the same path if the we make Postgres
an easy and effective alternative to SQL Server.

I would have a preference to have NULL = a_expr supported.  Access97 has
problems without it.  Of course, I am will to insert this change in my local
source tree.  

Thanks, Michael

> -----Original Message-----
> From:    Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
> Sent:    Monday, May 10, 1999 1:02 PM
> To:    Thomas G. Lockhart
> Cc:    PostgreSQL-development
> Subject:    [HACKERS] NULL = col
> 
> > > > 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