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
