Andres Freund <andres@anarazel.de> writes:
> On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
>> 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.
Many people rely on UUIDs being impervious to chance collisions, so
it's not clear to me why uniqueness within 63 characters is unachievable.
Even more, if you can't do it in 63, what makes you think that 100 is
better?
Also, is a length limit really more onerous than the ASCII-only
restriction you proposed? (As an ASCII-only kind of guy, it wouldn't
bother me any; but I suspect much of the world would beg to differ.)
>> 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.
If you had both 1 and 1 + 2^20 in there, the existing unique index would
not complain, but in practice those are duplicate entries, no? If you
make the column smallint such a case would be physically impossible.
regards, tom lane