On Tue, Nov 30, 1999 at 05:27:33PM +0100, Peter Eisentraut wrote:
> On Tue, 30 Nov 1999, Ross J. Reedstrom wrote:
>
<snipped me saying NULL constraint not in SQL92 standard>
>
> That's a pretty strong reason, in absence of any other good ones. The
> product is called PostgreSQL and not PostgreSybase or whatever. We
> shouldn't have to follow other vendors' questionable decisions. It's not
> really that hard to prepare any incompatible dumps you might have.
Really? can you give me an awk or sed pattern that easily disambiguates the
use of NULL as a pseudo column constraint from all of its other uses? I
probably can, but that's not useful if the code is being generated on the
fly by some commerical tool, is it?
My feeling on PostgreSQL, SQL standards, and vendor specific compatibility
options is: "be generous with what you accept, strict with what you
create" or something to that effect. We already have a number of vendor
extension compatiblity features in place[1]. Should all of those be ripped
out as well? If this accepting NULL pseudo constrains _costs us nothing_,
why not do it? I agree that implementing missing SQL92 standard features
is more important, and if this NULL actually interfered with anything
else, I'd see your point: straight to the bit bucket with it. But I don't
understand the resistance to a costless extension. The SQL standards
are certainly not holy writ, especially in regards to what they leave out.
Ross
[1] at least, I _think_ we do. Can't seem to list them, right off hand. I
do know a number of cases where ambigous wording in the standard has
been settled by asking "how do the other DBMSs do it?" As in "What will
an experienced DBA expect?"
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
