From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cataloguing NOT NULL constraints |
Date: | 2011-07-23 11:40:12 |
Message-ID: | CA+TgmoaT7Np=k39aH=D=dpRYKJ=gwXmRMA029BBs0jBs--fD6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> That looks wrong to me, because a NOT NULL constraint is a column
> constraint not a table constraint. The CREATE TABLE syntax explicitly
> distinguishes these 2 cases, and only allows NOT NULLs in column
> constraints. So from a consistency point-of-view, I think that ALTER
> TABLE should follow suit.
>
> So the new syntax could be:
>
> ALTER TABLE table_name ALTER [COLUMN] col_name ADD column_constraint
>
> where column_constraint is the same as in CREATE TABLE (i.e., allowing
> all the other constraint types at the same time).
>
> It looks like that approach would probably lend itself to more
> code-reusability too, especially once we start adding options to the
> constraint.
So you'd end up with something like this?
ALTER TABLE foo ALTER COLUMN bar ADD CONSTRAINT somename NOT NULL
That works for me. I think sticking the name of the constraint in
there at the end of the line as Alvaro proposed would be terrible for
future syntax extensibility - we'll be much less likely to paint
ourselves into a corner with something like this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-07-23 12:45:33 | Problem with pg_upgrade's directory write check on Windows |
Previous Message | Andrew Dunstan | 2011-07-23 10:51:35 | Re: Questions and experiences writing a Foreign Data Wrapper |