Re: ALTER TABLE modifications - Mailing list pgsql-patches

From Hannu Krosing
Subject Re: ALTER TABLE modifications
Date
Msg-id 1068722899.4751.16.camel@fuji.krosing.net
Whole thread Raw
In response to Re: ALTER TABLE modifications  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: ALTER TABLE modifications
List pgsql-patches
Peter Eisentraut kirjutas K, 12.11.2003 kell 21:02:
> Rod Taylor writes:
>
> > ALTER TABLE tab ADD COLUMN col DEFAULT 3, ADD CHECK (anothercol > 3);
> >         The above combinational syntax is commented out in gram.y. The
> >         support framework is used in both the above and below items, but
> >         arbitrary statements probably have some issues -- I've not
> >         tested enough to determine.
> >
> >         If it is useful, it will be submitted at a later date.
>
> I think it's perfectly fine to write two separate ALTER TABLE statements.

I guess the difference is that each pass (i.e. ALTER TABLE) needs to do
another scan and copy of the table. Putting them in one statement allows
all the alterations to be done in one pass.

> No need to introduce this nonstandard syntax.
>
> > ALTER TABLE tab ALTER COLUMN col TYPE text TRANSFORM ...;
> >         Currently migrates indexes, check constraints, defaults, and the
> >         column definition to the new type with optional transform. If
> >         the tranform is not supplied, a standard assignment cast is
> >         attempted.
>
> Please don't use the term "transform".  It is used by the SQL standard for
> other purposes.

Is the "other" use conflicting with this syntax ?

I think we have preferred reusing existing keywords to adding new ones
in the past.

-----------------
Hannu


pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [pgsql-hackers-win32] initdb in C
Next
From: Andrew Dunstan
Date:
Subject: Re: [pgsql-hackers-win32] initdb in C