Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?
От | Alvaro Herrera |
---|---|
Тема | Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL? |
Дата | |
Msg-id | 20140620205000.GX18688@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?
|
Список | pgsql-hackers |
Tom Lane wrote: > The idea I'm toying with right now is to additionally mark as not nullable > any column referenced in a DECLARE_UNIQUE_INDEX command in > catalog/indexing.h. But I've not looked through that set carefully; it's > conceivable that we actually have some indexed catalog columns that are > allowed to be null. A possibly better solution is to invent a new macro > that has the same semantics as DECLARE_UNIQUE_INDEX, plus forcing the > columns to be marked NOT NULL. I think most, if not all, the unique indexes declared are part of a syscache. I don't think we allow those to be null, so in effect those columns are already not nullable. Non-unique indexes in indexing.h already bear a standard comment that they are not used for syscache. The only exception was added recently in f01d1ae3a104019: DECLARE_INDEX(pg_class_tblspc_relfilenode_index, 3455, on pg_class using btree(reltablespace oid_ops, relfilenode oid_ops)); -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: