On Tue, 26 Mar 2002, Christopher Kings-Lynne wrote:
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > > I have throught of at least two problems with changing nullability. The
> > > first is primary keys. I have to prevent people setting a
> > column involved
> > > in a PK to null, r
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What about temporary tables - is there any reason they shouldn't be able to
> modify a temporary table?
I don't see one.
> What about indices? Will twiddling the nullability break indices on a table
> in any way?
No, not as long as you ar
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > I have throught of at least two problems with changing nullability. The
> > first is primary keys. I have to prevent people setting a
> column involved
> > in a PK to null, right?
>
> Probably so.
What about temporary tables - is there a
> ALTER TABLE blah ALTER [COLUMN] col SET NOT NULL;
>
> and
>
> ALTER TABLE blah ALTER [COLUMN] col DROP NOT NULL;
>
> This is synchronous with the SET/DROP default stuff and is
> extensible in the
> future to fit in with column type changing.
>
> Of course, it can always be changed in the parser
> OK, how about:
>
> SET CONSTRAINT NOT NULL
>
> or
>
> DROP CONSTRAINT NOT NULL
>
> or simply:
>
> SET/DROP NOT NULL
>
> I think the problem with trying to get it look like CREATE TABLE is that
> the plain NULL parameter to CREATE TABLE is meaningless and probably
> should never
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I have throught of at least two problems with changing nullability. The
> first is primary keys. I have to prevent people setting a column involved
> in a PK to null, right?
Probably so.
> The second is DOMAINs - what if they change a NOT N
> You could possibly make it work if you were willing to include the word
> TYPE when trying to respecify column type:
>
> ALTER TABLE blah ALTER [COLUMN] col [TYPE int4] [NOT NULL] [DEFAULT 32];
>
> Also I agree with Fernando that trying to make the word COLUMN optional
> is likely to lead to con
Thomas Lockhart wrote:
> ...
> > "CREATE TABLE test (x int NULL)" doesn't look great either. :-) What
> > is that NULL doing there?
>
> Well, because NOT NULL *was* in the standard, and because one should be
> able to explicitly negate *that*. The alternative was
>
> CREATE TABLE test (x int
...
> "CREATE TABLE test (x int NULL)" doesn't look great either. :-) What
> is that NULL doing there?
Well, because NOT NULL *was* in the standard, and because one should be
able to explicitly negate *that*. The alternative was
CREATE TABLE test (x int NOT NOT NULL)
:O
Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > BTW, is NULLABLE so ugly that no one wanted to comment on it?
>
> I kinda liked it, actually, if we were going to use the SET syntax.
> But people seem to be focused in on this "let's make it look like
> CREATE" notion. I'm wi
On Fri, 2002-03-22 at 14:00, Ross J. Reedstrom wrote:
> BTW, is NULLABLE so ugly that no one wanted to comment on it? It _is_
> an sql92 reserved keyword, and it's actual english grammar.
FWIW, I liked it the best of all the solutions that have been proposed
so far.
Cheers,
Neil
--
Neil Conwa
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> BTW, is NULLABLE so ugly that no one wanted to comment on it?
I kinda liked it, actually, if we were going to use the SET syntax.
But people seem to be focused in on this "let's make it look like
CREATE" notion. I'm willing to wait and see how fa
On Fri, Mar 22, 2002 at 01:12:09PM -0500, Tom Lane wrote:
>
> Also I agree with Fernando that trying to make the word COLUMN optional
> is likely to lead to conflicts.
According to the docs, COLUMN is _already_ optional at that point.
Are the changes past that point going to cause different prob
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> ALTER TABLE blah ALTER [COLUMN] col [int4] [NOT NULL] [DEFAULT 32];
> ALTER TABLE blah ALTER [COLUMN] col [int8] [NULL] [DEFAULT 32];
This cannot work unless you are prepared to turn a lot more keywords
into reserved words. In the CREATE
Zeugswetter Andreas SB SD wrote:
>
> Imho it would be nice if the command would look exactly like a create
> table. It is simply convenient to use cut and paste :-) And I haven't
> seen a keyword yet, that would make it more descriptive, certainly not SET.
>
> ALTER TABLE blah ALTER [COLUMN] col
Christopher Kings-Lynne writes:
> So then how is it any more wrong than SET NOT NULL?
You're right.
> It should almost be ADD NOT NULL ...
I like that.
It also makes sense because the standard syntax is to ADD/DROP CHECK
constraints, to which NOT NULL constraints are equivalent.
--
Peter Ei
seems like other systems keep very similar syntax to the CREATE TABLE
command. i.e.
ALTER TABLE blah ALTER COLUMN col datatype (precision.scale) NULL
ALTER TABLE blah ALTER COLUMN col datatype (precision.scale) NOT NULL
Dwayne
---(end of broadcast)--
> > Do we want the above syntax, or this syntax:
> >
> > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > ALTER TABLE blah ALTER COLUMN col SET NULL;
>
> My only objection to the second command is that it's plain wrong. You
> don't set anything to NULL, so don't make the command look like it
On March 22, 2002 01:31 am, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
> > Do we want the above syntax, or this syntax:
> >
> > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > ALTER TABLE blah ALTER COLUMN col SET NULL;
>
> My only objection to the second command is that it's pl
On Fri, Mar 22, 2002 at 02:34:57PM +0800, Christopher Kings-Lynne wrote:
> > > Do we want the above syntax, or this syntax:
> > >
> > > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > > ALTER TABLE blah ALTER COLUMN col SET NULL;
> >
> > My only objection to the second command is that it's pl
> > Do we want the above syntax, or this syntax:
> >
> > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > ALTER TABLE blah ALTER COLUMN col SET NULL;
>
> My only objection to the second command is that it's plain wrong. You
> don't set anything to NULL, so don't make the command look like it.
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Say in the future we want to support changing column type as well. How
> > would we work that in?
>
> > ALTER TABLE blah ALTER COLUMN col SET int4; ??
>
> Seems one keyword shy of a load; I'd prefer
>
> ALTER TABL
Christopher Kings-Lynne writes:
> Do we want the above syntax, or this syntax:
>
> ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> ALTER TABLE blah ALTER COLUMN col SET NULL;
My only objection to the second command is that it's plain wrong. You
don't set anything to NULL, so don't make the co
> Seems one keyword shy of a load; I'd prefer
>
> ALTER TABLE blah ALTER COLUMN col SET TYPE int4;
>
> Otherwise, every keyword that might appear after SET will have to be
> fully reserved (else it couldn't be distinguished from a type name).
I like that...
So would you then envisage something l
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Say in the future we want to support changing column type as well. How
> would we work that in?
> ALTER TABLE blah ALTER COLUMN col SET int4; ??
Seems one keyword shy of a load; I'd prefer
ALTER TABLE blah ALTER COLUMN col SET TYPE i
Hi,
I'm halfway thru implementing setting a column's nullness (I've done
changing to null,
but not changing to not null)
Peter E. said:
> Using the standard precedent above, how about
>
> ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> ALTER TABLE blah ALTER COLUMN col DROP NOT NULL;
Do we w
26 matches
Mail list logo
