NULL = col

-----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

-----Original Message-----
From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
Sent: Monday, May 10, 1999 1:30 PM
To: Michael J Davis
Cc: Thomas G. Lockhart; PostgreSQL-development
Subject: Re: [HACKERS] NULL = col

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.

Maybe we only need to have it working where we have already added it,
and not all over the place. We can release what we have, which hits %95
of the NULL = col uses, and wait and see if people have problems trying
to do this non-standard thing someplace else.

-- 
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