From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | MS Access vs IS NULL (was Re: [BUGS] Bug in SQL functions that use a NULL parameter directly) |
Date: | 2001-01-14 19:00:04 |
Message-ID: | 938.979498804@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> Because of Access's brokenness, the parser or some other layer of the
> code "fixes" explicit = NULL (ie, in the actually query string) into
> IS NULL which is the correct way to check for nulls.
> Because your original query was = $1, it doesn't do the mangling of the
> SQL to change into IS NULL when $1 is NULL. The fact that we do that
> conversion at all actually breaks spec a little bit but we have little
> choice with broken clients.
It seems to me that we heard awhile ago that Access no longer generates
these non-spec-compliant queries --- ie, it does say IS NULL now rather
than the other thing. If so, it seems to me that we ought to remove the
parser's = NULL hack, so that we have spec-compliant NULL behavior.
Anyone recall anything about that? A quick search of my archives didn't
turn up the discussion that I thought I remembered.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2001-01-14 19:05:18 | RE: MS Access vs IS NULL (was Re: [BUGS] Bug in SQL functions that use a NULL parameter directly) |
Previous Message | Rehak Tamas | 2001-01-14 17:26:35 | copy from stdin; bug? |