Re: creating CHECK constraints as NOT VALID
От | Thom Brown |
---|---|
Тема | Re: creating CHECK constraints as NOT VALID |
Дата | |
Msg-id | BANLkTimWanXbnJpfP9bvt-G2MLN8uFfMTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: creating CHECK constraints as NOT VALID (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: creating CHECK constraints as NOT VALID
|
Список | pgsql-hackers |
On 11 June 2011 14:32, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > On 1 June 2011 23:47, Alvaro Herrera <alvherre@commandprompt.com> wrote: >> >> Here's a complete patch with all this stuff, plus doc additions and >> simple regression tests for the new ALTER DOMAIN commands. >> >> Enable CHECK constraints to be declared NOT VALID >> >> This means that they can initially be added to a large existing table >> without checking its initial contents, but new tuples must comply to >> them; a separate pass invoked by ALTER TABLE / VALIDATE can verify >> existing data and ensure it complies with the constraint, at which point >> it is marked validated and becomes a normal part of the table ecosystem. >> > > I think that you also need to update the constraint exclusion code > (get_relation_constraints() or nearby), otherwise the planner might > exclude a relation on the basis of a CHECK constraint that is not > currently VALID. Do the standards explicitly stipulate an expected behaviour for this? And does such a problem affect the invalid foreign key change too? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: