Thread
-
NULL
Goran Thyni <goran@kirra.net> — 1999-11-15T19:07:06Z
How about this according to SQL standard: CREATE TABLE x { y integer NULL }; It suppose to mean that NULLs are explicitly allowed in this field. Is this required by SQL-92? TIA, -- ----------------- Göran Thyni On quiet nights you can hear Windows NT reboot! -
Re: [SQL] NULL
Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-15T19:23:58Z
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > How about this according to SQL standard: > > CREATE TABLE x { y integer NULL }; > > It suppose to mean that NULLs are explicitly allowed in > this field. > Is this required by SQL-92? If I remember correctly, only NOT NULL is supported by SQL-92. Thomas talked about adding support for it in some limited cases for 7.0. There are shift/reduce cases if it were allowed everywhere. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -
Re: [SQL] NULL
Bruce Stephens <bruce@cenderis.demon.co.uk> — 1999-11-15T19:57:46Z
Goran Thyni <goran@kirra.net> writes: > How about this according to SQL standard: > > CREATE TABLE x { y integer NULL }; > > It suppose to mean that NULLs are explicitly allowed in > this field. > Is this required by SQL-92? No, it's not required. This came up before with the examples from "The Practical SQL Handbook". It would be nice to allow it, but there was some reason why to do so would be non-trivial, which I forget. Anyway, it's not in SQL-92. -
Re: [SQL] NULL
Jan Wieck <wieck@debis.com> — 1999-11-15T23:48:21Z
Bruce Momjian wrote: > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > > > How about this according to SQL standard: > > > > CREATE TABLE x { y integer NULL }; > > > > It suppose to mean that NULLs are explicitly allowed in > > this field. > > Is this required by SQL-92? > > If I remember correctly, only NOT NULL is supported by SQL-92. Thomas > talked about adding support for it in some limited cases for 7.0. There > are shift/reduce cases if it were allowed everywhere. Hmmm, I can't see any shift/reduce conflicts if I place a | NULL_P case into the ColConstraintElem: definition right between the | DEFAULT b_expr and | NOT NULL_P cases. Could it be that this reason is out of date? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) # -
Re: [SQL] NULL
Jose Soares <jose@sferacarta.com> — 1999-11-16T13:37:05Z
Bruce Stephens ha scritto: > Goran Thyni <goran@kirra.net> writes: > > > How about this according to SQL standard: > > > > CREATE TABLE x { y integer NULL }; > > > > It suppose to mean that NULLs are explicitly allowed in > > this field. > > Is this required by SQL-92? > > No, it's not required. This came up before with the examples from > "The Practical SQL Handbook". It would be nice to allow it, but there > was some reason why to do so would be non-trivial, which I forget. > Anyway, it's not in SQL-92. > > ************ Sorry, I don't understand why we need this feature. This is completely out of standard. What's that mean ? - Is it a constraint to allow only NULL values ? (unuseful) - If this is a default value we already have this in: CREATE TABLE table1 (field1 int DEFAULT NULL); - According with SQL-92 every column can store a NULL value by default unless one specify a NOT NULL constraint for the column. José -
Re: [SQL] NULL
Jan Wieck <wieck@debis.com> — 1999-11-16T14:16:08Z
> > > It suppose to mean that NULLs are explicitly allowed in > > > this field. > > > Is this required by SQL-92? > > > > No, it's not required. This came up before with the examples from > > "The Practical SQL Handbook". It would be nice to allow it, but there > > was some reason why to do so would be non-trivial, which I forget. > > Anyway, it's not in SQL-92. > > > Sorry, I don't understand why we need this feature. This is completely ou= > t > of standard. > > What's that mean ? > > - Is it a constraint to allow only NULL values ? (unuseful) Useless? I NEED IT - URGENT - NOW - YESTERDAY. Then I could create my tables with all required fields for the future, but prevent that someone stores data in them until I drop the constraint. I vote for this :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) # -
Re: [SQL] NULL
Jose Soares <jose@sferacarta.com> — 1999-11-17T13:56:16Z
Jan Wieck ha scritto: > > > > It suppose to mean that NULLs are explicitly allowed in > > > > this field. > > > > Is this required by SQL-92? > > > > > > No, it's not required. This came up before with the examples from > > > "The Practical SQL Handbook". It would be nice to allow it, but there > > > was some reason why to do so would be non-trivial, which I forget. > > > Anyway, it's not in SQL-92. > > > > > Sorry, I don't understand why we need this feature. This is completely ou= > > t > > of standard. > > > > What's that mean ? > > > > - Is it a constraint to allow only NULL values ? (unuseful) > > Useless? I NEED IT - URGENT - NOW - YESTERDAY. > > Then I could create my tables with all required fields for > the future, but prevent that someone stores data in them > until I drop the constraint. Maybe I miss something here, Jan...I think you don't need such thing to do this kind of work. To drop the constraint you have: 1) download the table 2) modify the table structure (without constraint NULL) 3) re-create the table 4) reload it again. You have the same effect as: 1) download the table 2) add new filelds to table structure 3) re-create the table 4) reload it again ...but, if want these fields from the begining you may create a CHECK contraint for the field, like: CREATE TABLE distributors ( did DECIMAL(3), name VARCHAR(40), avoid INTEGER CONSTRAINT con1 CHECK (avoid is NULL) ); insert into distributors values (33,'PIPPO',123); ERROR: ExecAppend: rejected due to CHECK constraint con1 insert into distributors values (33,'PIPPO',NULL); INSERT 1484300 1 select * from distributors; did|name |avoid ---+-----+----- 33|PIPPO| (1 row) ...and this is SQL-92 Standard ;) José -
Re: [SQL] NULL
Jan Wieck <wieck@debis.com> — 1999-11-17T18:31:28Z
> Jan Wieck ha scritto: > > > > - Is it a constraint to allow only NULL values ? (unuseful) > > > > Useless? I NEED IT - URGENT - NOW - YESTERDAY. > > Maybe I miss something here, Jan... Yepp - my smiley on the last line. It wasn't a serious comment. More a joke and I really mean that such a definition is absolutely not needed. Maybe I'm writing too much between the lines. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) # -
Re: [SQL] NULL
Bruce Stephens <bruce@cenderis.demon.co.uk> — 1999-11-24T15:08:11Z
jose soares <jose@sferacarta.com> writes: > Bruce Stephens ha scritto: > > No, it's not required. This came up before with the examples from > > "The Practical SQL Handbook". It would be nice to allow it, but there > > was some reason why to do so would be non-trivial, which I forget. > > Anyway, it's not in SQL-92. > - According with SQL-92 every column can store a NULL value by default > unless one specify a NOT NULL constraint for the column. Yes. NULL would just mean that NULLs are permitted. So it's not required, obviously (since this is the default). However, many books recommend that you should generally not allow NULLs: thus, if you force yourself to explicitly say "NULL" or "NOT NULL", that ought to be a prompt to consider the issue (and you can spot cases which you may not have thought about by the absence of either). I imagine that's why "The Practical SQL Handbook" suggests it.