On 2015-05-18 19:59:29 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
