Re: Catalog domain not-null constraints
От | Peter Eisentraut |
---|---|
Тема | Re: Catalog domain not-null constraints |
Дата | |
Msg-id | dd3bdf0e-a622-4111-9cba-1c458d70afb6@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Catalog domain not-null constraints (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Catalog domain not-null constraints
|
Список | pgsql-hackers |
On 21.03.24 12:23, Peter Eisentraut wrote: >> All the examples in the tests append "value" to this, presumably by >> analogy with CHECK constraints, but it looks as though anything works, >> and is simply ignored: >> >> ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL xxx; -- works >> >> That doesn't seem particularly satisfactory. I think it should not >> require (and reject) a column name after "NOT NULL". > > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses > table constraint syntax. As long as you are only dealing with CHECK > constraints, there is no difference, but it shows up when using NOT NULL > constraint syntax. I agree that this is unsatisfactory. Attached is a > patch to try to sort this out. After studying this a bit more, I think moving forward in this direction is the best way. Attached is a new patch version, mainly with a more elaborate commit message. This patch makes the not-null constraint syntax consistent between CREATE DOMAIN and ALTER DOMAIN, and also makes the respective documentation correct. (Note that, as I show in the commit message, commit e5da0fe3c22 had in passing fixed a couple of bugs in CREATE and ALTER DOMAIN, so just reverting that commit wouldn't be a complete solution.)
Вложения
В списке pgsql-hackers по дате отправления: