Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |
| Дата | |
| Msg-id | f88ddb82-1d6d-459d-8b9f-e75f07977ec3@eisentraut.org обсуждение исходный текст |
| Ответ на | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
|
| Список | pgsql-hackers |
On 03.04.25 10:07, Alvaro Herrera wrote: > The new flag is there for quick access by get_relation_info. We could > easily not have it otherwise, because clients don't need it, but its > lack would probably make planning measurably slower because it'd have to > do syscache access for every single not-null constraint to figure out if > it's valid or not. In the v6 patch, you are adding a attnullability field to the CompactAttribute in the tuple descriptor and use that in get_relation_info(). That seems like the right approach, because then you're doing all that preprocessing about which constraint is active in the relcache. So I don't see where the extra pg_attribute field attnotnullvalid is getting used.
В списке pgsql-hackers по дате отправления: