Re: NOT NULL markings for BKI columns

On 2015-02-15 12:54:45 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > Hm, I was thinking about
> > /* extversion should never be null, but the others can be. */
> > text extversion PG_FORCENOTNULL; /* extension version name */
> > but pgindent then removes some of the space between text and extversion,
> > making it
> > text extversion PG_FORCENOTNULL; /* extension version name */
> > an alternative where it doesn't do that is
> > text PG_FORCENOTNULL(extversion); /* extension version name */
>
> > Not sure what's the best way here.
>
> The former is clearly a lot more sane semantically, so I'd go with
> that even if the whitespace is a bit less nice.

Yea.

> I notice that pgindent does a similar not-very-nice thing with
> PG_USED_FOR_ASSERTS_ONLY. I wonder if we could hack it to handle
> those two identifiers specially?

I looked for about a minute and it didn't seem trivial to
do. Unfortunately that's pretty much all I'm willing to do.

> BTW, the precedent of PG_USED_FOR_ASSERTS_ONLY would suggest calling
> this one PG_FORCE_NOT_NULL, or at least using underscores for word
> breaks in whatever we end up calling it.

I've named it BKI_FORCE_(NOT_)?NULL.

So, I've implemented this - turned out to be a bit more work than I'd
expected... I had to whack around the representation Catalog.pm returns
for columns, but I think the new representation for columns is better
anyway. Doesn't look too bad.

The second patch attached adds BKI_FORCE_NOT_NULL marker to the system
columns that, based on a single scan through the relevant headers, are
missing NOT NULL.

I've also added BKI_FORCE_NULL as you mentioned it as being possibly
useful, was easy enough. I haven't identified a user so far though, so
we could just remove it if we want.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services