Re: Shouldn't pg_(sh)seclabel.provider be marked NOT NULL?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Jun 20, 2014, at 10:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Some of my Salesforce colleagues are looking into making every system
>> catalog be declared with a true primary key. They came across the
>> fact that pg_seclabel and pg_shseclabel are declared with unique
>> indexes that include the "provider" column, but that column does not
>> get marked as NOT NULL during initdb. Shouldn't it be?

> At some point, I inferred a rule that catalog columns were intended to
> be either both fixed-width and not nullable; or variable-width and
> nullable. I believe the current situation is the result of that
> inference... but I see no particular reason not to change it.

The actual rule that's embodied in the bootstrap code is to mark
everything that could potentially be referenced via a C struct field
as not nullable: which is to say, fixed-width fields up till we get
to the first variable-width one. It's fairly likely that this is *not*
marking all the columns that the code expects to be non-null in practice.

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.

A bigger-picture question is whether there are yet more columns that
could be marked not null, and how much we care about making them so.

regards, tom lane