All good points.
The ability to store NULL, and the fact that there is just one kind of
NULL, seem to parallel what has become common and useful in
programming languages. Most support NULL at least for pointers, and
many support it for all data types. It doesn't have to have a defined
meaning to
[EMAIL PROTECTED] (Greg Stark) writes:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
>
>> However, there are often nulls that fall in the category of "who
>> cares?" For those, null is a perfectly acceptable alternative, and
>> there's no need for all the extra work.
>
> There is often a need for sp
Scott Marlowe <[EMAIL PROTECTED]> writes:
> However, there are often nulls that fall in the category of "who
> cares?" For those, null is a perfectly acceptable alternative, and
> there's no need for all the extra work.
There is often a need for special case values. Situations like "subscriptio
On Mon, 2006-07-03 at 11:09, Scott Ribe wrote:
> > Can't the intelligent practitioner simply proceed carefully with
> > queries when nulls are involved?
>
> Yes. The thing is, getting rid of NULL in the real world requires
> decomposing data into so many tables that it would certainly cause more
>
> Can't the intelligent practitioner simply proceed carefully with
> queries when nulls are involved?
Yes. The thing is, getting rid of NULL in the real world requires
decomposing data into so many tables that it would certainly cause more
confusion when it comes time to actually query the data...
On Wed, Jun 28, 2006 at 02:43:03AM -0700, [EMAIL PROTECTED] wrote:
> 'Scuse my broken english and ungrammatical gibberish in my last
> missive. That's what I get for posting before my first cup of
> coffee for the day.
>
> I'm serious about nulls though, and am wondering if Date and Pascal,
> per
y, June 28, 2006 8:45 AM
To: Berend Tober
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Null and Void() - Or, Abandon All Hope Ye Who allow
Well, yes - as I said, using null values gives you more flexibility. But
still, you _can_ shoot yourself in the foot by using them - that's why
On Wed, Jun 28, 2006 at 02:31:20AM -0700, [EMAIL PROTECTED] wrote:
> Date and Pascal hate nulls. One even goes so far as to say that if
> you permit NULLs in a database, then the results from *every* query
> is suspect. So they turn perform backflips suggesting ways to avoid
> nulls. None, so fa
On Wed, Jun 28, 2006 at 10:43:26AM -0400, A.M. wrote:
> NULL is nothing more than a shortcut. SQL logic has to do backflips to
> accomodate it- notice how NULL!=NULL- indeed, one NULL can mean a variety
> of things even in the same context! ("Bob doesn't know","HR doesn't
> know","No one cares","No
On Wed, June 28, 2006 5:31 am, [EMAIL PROTECTED] wrote:
> Date and Pascal hate nulls. One even goes so far as to say that if you
> permit NULLs in a database, then the results from *every* query is suspect.
> So they turn perform backflips suggesting ways to avoid nulls.
> None, so far, seem appeal
--- Andrew Gould <[EMAIL PROTECTED]> wrote:
> --- Berend Tober <[EMAIL PROTECTED]> wrote:
>
> > Florian G. Pflug wrote:
> > > [EMAIL PROTECTED] wrote:
> > >
> > >> Date and Pascal hate nulls.
> > >
> > > ...the functions described by those functional
> > dependencies are
> > > not require
--- Berend Tober <[EMAIL PROTECTED]> wrote:
> Florian G. Pflug wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >> Date and Pascal hate nulls.
> >
> > ...the functions described by those functional
> dependencies are
> > not required to be defined for every possible
> value - let's say you have
>
Berend Tober wrote:
Florian G. Pflug wrote:
> [EMAIL PROTECTED] wrote:
>
>> Date and Pascal hate nulls.
>
> ...the functions described by those functional dependencies are
> not required to be defined for every possible value - let's say you have
> a function dependency A -> B - meaning th
Florian G. Pflug wrote:
> [EMAIL PROTECTED] wrote:
>
>> Date and Pascal hate nulls.
>
> ...the functions described by those functional dependencies are
> not required to be defined for every possible value - let's say you have
> a function dependency A -> B - meaning that whenever you know the val
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is
suspect. So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem appealing.
To me, nulls are quite useful i
'Scuse my broken english and ungrammatical gibberish in my last
missive. That's what I get for posting before my first cup of coffee
for the day.
I'm serious about nulls though, and am wondering if Date and Pascal,
perhaps, are the gibberish ones on this particular issue. The
insistence on no null
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is
suspect. So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem appealing.
To me, nulls are quite useful in the Real World. For insta
At 10:39 PM 05-12-1999 -0500, Mike Mascari wrote:
>I would just do:
>
>SELECT users.usr_id, users.usr_login FROM users WHERE NOT EXISTS
> (SELECT wm_accounts.usr_id FROM wm_accounts WHERE
> wm_accounts.usr_id = users.usr_id);
OK, my current query is
select usr_id,usr_login from users where usr_i
Lincoln Yeoh wrote:
> At 04:59 PM 05-12-1999 -0500, Mike Mascari wrote:
> >Instead, I would use a correlated subquery with an EXISTS/NOT EXISTS test
> >against the criteria for which you are searching:
> >
> >SELECT t1.a, t1.b FROM dummy t1
> >WHERE EXISTS (SELECT t2.a FROM dummy t2 WHERE t1.a =
At 04:59 PM 05-12-1999 -0500, Mike Mascari wrote:
>Instead, I would use a correlated subquery with an EXISTS/NOT EXISTS test
>against the criteria for which you are searching:
>
>SELECT t1.a, t1.b FROM dummy t1
>WHERE EXISTS (SELECT t2.a FROM dummy t2 WHERE t1.a = t2.a)
>
>
I've got two table
Mike Mascari wrote:
>
> I would avoid using the INTERSECT/EXCEPT code since the query rewriter
> rewrites these to IN clauses which cannot use indexes. As soon as the tables
> grow beyond more than a couple hundred rows, the statment becomes unusable.
> Instead, I would use a correlated subquery
Slavica Stefic wrote:
> Hello,
>
> is null = null true or also null ?
NULL = NULL is also NULL (or more explicity, UNKNOWN, implemented as NULL).
Since NULL means "unknown/not applicable" we don't know whether two
"unknowns" are, in fact, equal, and that is what the standard says - at
least acco
Slavica Stefic wrote:
> is null = null true or also null?
A null value represents either the absence of data or
an unknown value. A null value is not
the same as a zero or a blank.
Thus two tuples with null values are never the same and can not
be joined.
> it appears that two null records a
Hello,
is null = null true or also null ?
more precisely I have this kind of situation in a mission critical
project and I'm,sadly, not an expert in SQL.
But until now I used null values with a specific meaning in my database,
and I didn't knew that
I would come in this situation:
=>create tabl
24 matches
Mail list logo
