Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?
Date
Msg-id 20140620205000.GX18688@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?
Next
From: Andres Freund
Date:
Subject: Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?