Hi!
I probably found an inconsistence of the working of the =
operator. Please read ahead, if you're interested.
I have two tables, let't call them a and b. They are:
a)
x | y
-
1 | 100
2 | NULL
b)
y | z
--
Sorry, I made a mistake in my previous letter,
the table b looks like this:
b)
y | z
100 (not 1) | 'Hallelujah'
NULL| 'Hmm...'
Bye,
Baldvin
---(end of broadcast)---
TIP 5: Have you checked our extensiv
On Sun, 16 Sep 2001, Kovacs Baldvin wrote:
> select NULL = NULL;
>
> The answer is: true!!!
This has got to be a bug. NULL is not equal to anything (nor is it
unequal to anything).
SQL uses tri-valued logic, where answers are either true, false, or
unknown.
When selecting where a = b, if eith
Richard NAGY <[EMAIL PROTECTED]> writes:
> SELECT aes.ent_id, e.type, e.nom, aes.sect_id as voulu,
> cvd_new(current_date, e.date_entree, 'new') FROM ass_entrep_sectact aes,
> entreprise e WHERE e.id = aes.ent_id and aes.sect_id <> 3 and
> aes.sect_id <> 9
> and aes.sect_id <> 1 and aes.sect_id <>
Tod McQuillin <[EMAIL PROTECTED]> writes:
> On Sun, 16 Sep 2001, Kovacs Baldvin wrote:
>> select NULL = NULL;
>>
>> The answer is: true!!!
> This has got to be a bug. NULL is not equal to anything (nor is it
> unequal to anything).
Indeed, this *should* yield NULL. But right now, postgres' pa
On Mon, 17 Sep 2001, Tod McQuillin wrote:
> On Sun, 16 Sep 2001, Kovacs Baldvin wrote:
>
> > select NULL = NULL;
> >
> > The answer is: true!!!
>
> This has got to be a bug. NULL is not equal to anything (nor is it
> unequal to anything).
This is because of a hack due to a broken MS client th
Tom,
> [ Sorry for slow response, I've been out of town ]
Taking a much-deserved vacation, hey? Any new job plans?
> Postgres absolutely does not care: the optimizer will always consider
> both A-join-B and B-join-A orders for every join it has to do. As
> Stephan and Josh noted, you can cons
Hi again.
First of all, tank you for the immediate and precise answers.
My solution to the problem was the following. However, I found
that to be quite slow. I would like to ask if one can suggest me
how to optimize this, because I need this regularly.
CREATE FUNCTION gyegyenlo(text, text) RETU
Kovacs Baldvin <[EMAIL PROTECTED]> writes:
> After these I use ~= if I need lines with NULLs in both to be selected.
Perhaps you should reconsider your data model. You seem to be treating
NULL as if it were a real value, which is something that SQL discourages
rather strongly...
