On Tue, 19 Sep 2000, Glenn Linderman wrote:
> > I agree that undef and NULL have different semantics. However, this is
> > clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
> > just because we occasionally have to interface with their system.
>
> They are different. Neither is a mistake.
How do you explain the fact that every SQL book I've ever seen has
included copious text on problems concerning NULL? Why do so many RDBMs
implement NULL differently? If you can't agree that NULL was a mistake
you must at least realize that it's difficult for most programmers to
understand.
> > Perhaps you could show an example using DBI where having NULLs mapped to
> > undef is actually a problem?
>
> If one (you wouldn't, I suspect) wanted to write expressions in Perl that had
> the same semantics as expressions in SQL, which could come in handy for
> further manipulating data obtained from SQL, then mapping NULLs to undef
> doesn't make that easier.
That's not an example. What you just described is actually a bad idea.
If you want to program in SQL you know where to find it. Your code will
be faster if it runs in the SQL server and you'll have the full "power" of
SQL in your hands, NULLs and all.
Do you want to do pointer arithmetic in Perl with data you get from C
programs too?
> It is not a problem if all you do with DB data is retrieve and/or store. It
> is only a problem if you want to do DB style manipulations of the data.
Perl does not do "DB style" manipulation of data. Adding NULL won't
change that, you'll still be missing all that relational jazz that makes
SQL actually usefull - various flavors of joins, grouping, limiting,
indexing, etc. And no, I'm not suggesting that we add them.
> The semantics of NULL neither require nor desire warnings.
There's the problem. It's not just my problem, it's a problem for a large
portion of the users of SQL. NULLs just slide on by, masquerading as real
values but behaving like invaders from another dimension.
> If you want warnings, use strict and undef.
Under your plan DBI would be modified to return NULLs, right? How would I
"use strict and undef" then?
-sam
