Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
От | Tom Lane |
---|---|
Тема | Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch |
Дата | |
Msg-id | 4815.1308245105@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Re: starting to review the Extend NOT NULL
representation to pg_constraint patch
Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > So, question: do we need pg_constraint rows to exist for all NOT NULL > constraints, including those in system catalogs, and including those in > bootstrap catalogs? If we're going to require that, we're going to need > to add a few initial data lines to the pg_constraint catalog definition, > plus some code to handle the other bootstrap cases (non bootstrap > relations). Installing such rows during bootstrap would be problematic, because what do you do for catalogs that are created before pg_constraint? Possible solution is to leave bootstrap's behavior alone, and have a step during initdb's post-bootstrap stuff that creates a matching pg_constraint row for every pg_attribute entry that's marked attnotnull. > We could also declare that we don't need pg_constraint rows for NOT NULL > constraints in system catalogs; but if we're going to do that, I guess > we'd better disallow tables from inheriting system catalogs. I have a feeling that omitting these entries for system catalogs would bite us in other ways down the road, even if inheritance were the only soft spot right now. regards, tom lane
В списке pgsql-hackers по дате отправления: