Robert Haas <robertmh...@gmail.com> writes:
>> On Jun 20, 2014, at 10:01 AM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
