Re: collations in shared catalogs?

On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2015-05-18 19:23:59 -0400, Tom Lane wrote:
> > Hm, just forcing a collation and restricting the input to ascii should
> > work, right?
>
> I think that's fragile as can be. Is there a *really really* good
> argument why these things shouldn't be subject to identifier length
> restrictions?

It's maybe not absolutely strictly necessary. In fact in earlier
versions of the patch it was name. But replication solutions like bdr,
slony, whatever will have to store a bunch of values identifying a node
in there. And that's much easier if you're not constrained by 63 chars.

> >> While I'm looking at it, why in the world have roident and not just a
> >> standard system OID column? This catalog seems willfully ignorant of
> >> Postgres conventions.
>
> > There's a comment:
> > * Needs to fit into an uint16, so we don't waste too much space in WAL
> > * records. For this reason we don't use a normal Oid column here, since
> > * we need to handle allocation of new values manually.
>
> If it needs to fit into uint16, why not make it smallint? The declaration
> seems 100% misleading if it's not an OID.

smallint has a smaller range. I mean, we could use a smallint and just
store unsigned values nonetheless. But that'd be somewhat ugly, although
not without precedent (pg_class.relpages). There'll only ever be very
few rows in pg_replication_origin, so the wideness itself doesn't
matter.

One reason for leaving it a oid instead of a more fitting type is that
it'll make it much smother to increase the limit to full 32bit -
there'll be no user level change.

> Moreover, the catalog infrastructure is failing to help you make sure
> the values are unique.

Not sure what you mean? There's both a unique key and locking in place
to make sure that's not violated.

Greetings,

Andres Freund