On 10/20/2005 6:10 AM, Alban Hertroys wrote:
Michael Glaesemann wrote:
if (OLD.value IS NOT NULL and NEW.value IS NOT NULL and OLD.value <>
NEW.value) or OLD.value IS NULL or NEW.value IS NULL
But that's untested and I have a hard time thinking in three-value logic.
For completeness sake;
CSN <[EMAIL PROTECTED]> writes:
> BTW, it (the SQL spec I presume) has always seemed
> contradictory to me that you can't do:
> select * from table where field=null;
> but can do:
> update table set field=null;
This only seems contradictory if you fail to make the distinction
between "=" used as a
BTW, it (the SQL spec I presume) has always seemed
contradictory to me that you can't do:
select * from table where field=null;
but can do:
update table set field=null;
(as opposed to 'update table set field to null' or
similar).
CSN
__
On Oct 20, 2005, at 23:45 , Michael Fuhr wrote:
On Thu, Oct 20, 2005 at 03:57:41PM +0900, Michael Glaesemann wrote:
On Oct 20, 2005, at 15:44 , Michael Fuhr wrote:
expression IS DISTINCT FROM expression
For non-null inputs this is the same as the <> operator. However,
when both inputs
Tom Lane wrote:
Wrong. SQL doesn't guarantee lazy evaluation. The above will work,
but it's because TRUE OR NULL is TRUE, not because anything is promised
about evaluation order.
Learned something new again, then.
I also noticed FALSE OR NULL is NULL, which went against my intuition. I
thin
On Thu, Oct 20, 2005 at 03:57:41PM +0900, Michael Glaesemann wrote:
> On Oct 20, 2005, at 15:44 , Michael Fuhr wrote:
> > expression IS DISTINCT FROM expression
> >
> > For non-null inputs this is the same as the <> operator. However,
> > when both inputs are null it will return false, and when
Alban Hertroys <[EMAIL PROTECTED]> writes:
> Michael Glaesemann wrote:
>> if (OLD.value IS NOT NULL and NEW.value IS NOT NULL and OLD.value <>
>> NEW.value) or OLD.value IS NULL or NEW.value IS NULL
>>
>> But that's untested and I have a hard time thinking in three-value logic.
> For completen
Michael Glaesemann wrote:
if (OLD.value IS NOT NULL and NEW.value IS NOT NULL and OLD.value <>
NEW.value) or OLD.value IS NULL or NEW.value IS NULL
But that's untested and I have a hard time thinking in three-value logic.
For completeness sake; Because of lazy evaluation, that boils down to
On Oct 20, 2005, at 15:44 , Michael Fuhr wrote:
expression IS DISTINCT FROM expression
For non-null inputs this is the same as the <> operator. However,
when both inputs are null it will return false, and when just one
input is null it will return true. Thus it effectively acts as
On Wed, Oct 19, 2005 at 11:04:36PM -0700, CSN wrote:
> So, does NULL != 'abc' always evaluate to false?
It never evaluates to false -- it evaluates to NULL.
http://www.postgresql.org/docs/8.0/interactive/functions-comparison.html
The ordinary comparison operators yield null (signifying "unknow
On Oct 20, 2005, at 15:04 , CSN wrote:
So, does NULL != 'abc' always evaluate to false? The
manual
(http://www.postgresql.org/docs/8.0/interactive/functions-
comparison.html)
states don't compare NULL values using =, but nothing
about using !=
The SQL standard way of checking for NULL is us
I was trying this:
IF (OLD.value != NEW.value) THEN
--
END IF;
and couldn't get the condition to evaluate to true at
all if OLD.value was NULL. I also tried:
IF (OLD.value NOT LIKE NEW.value) THEN
--
END IF;
with the same result. But this works:
IF ((OLD.value is NULL and NEW.value is NOT NU
12 matches
Mail list logo
