Re: cataloguing NOT NULL constraints
От | Robert Haas |
---|---|
Тема | Re: cataloguing NOT NULL constraints |
Дата | |
Msg-id | CA+TgmoaT7Np=k39aH=D=dpRYKJ=gwXmRMA029BBs0jBs--fD6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: cataloguing NOT NULL constraints (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: cataloguing NOT NULL constraints
|
Список | pgsql-hackers |
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed <dean.a.rasheed@gmail.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
В списке pgsql-hackers по дате отправления: