Re: collations in shared catalogs?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: collations in shared catalogs?
Date: 2015-05-19 00:30:46
Message-ID: 20150519003046.GE9584@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-05-18 20:19:29 -0400, Tom Lane wrote:
> 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?

Well UUIDs are also hard to manage because they're pretty much bare of
any meaning. It's much easier to understand
'slony:{node=nodename,role=master,id=someid}' or similar than
'slony:cc70ac60-fdbd-11e4-b939-0800200c9a66'.

> 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.)

I don't think anybody is going to be too concerned about node names or
something similar being ascii only. There's already a more restrictive
naming policy in place for replication slots...

> 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.

There's an error check in place (ERROR, PROGRAM_LIMIT_EXCEEDED)
preventing it when creating a replication origin.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-05-19 01:14:15 Re: collations in shared catalogs?
Previous Message Tom Lane 2015-05-19 00:19:29 Re: collations in shared catalogs?