Interesting - my experience is that Access, at least, generally treats
NULL's correctly:
(This was done under Access 2000):
create table foo (name text(20))
insert into foo values ("bar");
insert into foo values ("bar");
insert into foo values ("bar");
insert into foo values ("bar");
insert into
Mike Mascari <[EMAIL PROTECTED]> writes:
> The best solution would be to have the ODBC translate instances of '=
> NULL' into IS NULL before submitting the query to PostgreSQL.
Does Access only talk to Postgres via ODBC? (Seems plausible, but I
don't know.) What about people copying-and-pastin
Mike Mascari <[EMAIL PROTECTED]> writes:
> The best solution would be to have the ODBC translate instances of '=
> NULL' into IS NULL before submitting the query to PostgreSQL. I'm
> sure this is how other vendors, like Oracle handle the issue. Well,
> probably sure... :-)
That's the intell
Tom Lane <[EMAIL PROTECTED]> writes:
> A compromise answer might be to offer a SET variable that selects the
> Microsoft-compatible misimplementation. Would that fly?
I'd say that's the best way to handle stuff like this. If you
implement something that breaks the standard, to be compatible wi
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> A compromise answer might be to offer a SET variable that selects the
>> Microsoft-compatible misimplementation. Would that fly?
> It would for me. I'd rather have the default be the spec correct behavior
> and let people configure their server to fo
> > Yes, column = NULL should *never* return true according to the spec (it
> > should always return NULL in fact as stated). The reason for breaking
> > with the spec is AFAIK to work with broken microsoft clients that seem to
> > think that =NULL is a meaningful test and generate queries using
On Wed, 6 Jun 2001, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Yes, column = NULL should *never* return true according to the spec (it
> > should always return NULL in fact as stated). The reason for breaking
> > with the spec is AFAIK to work with broken microsoft clients
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Yes, column = NULL should *never* return true according to the spec (it
> should always return NULL in fact as stated). The reason for breaking
> with the spec is AFAIK to work with broken microsoft clients that seem to
> think that =NULL is a meaningfu