From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndQuadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 9.4 Proposal: Initdb creates a single table |
Date: | 2014-04-24 16:53:11 |
Message-ID: | 838.1398358391@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> On Thu, Apr 24, 2014 at 11:30:15AM -0400, Tom Lane wrote:
>> Essentially, that would mean carrying around our own implementation
>> of libuuid --- which includes a bunch of not-terribly-portable
>> stuff, such as discovering the machine's MAC address(es). That's
>> not really something I want to see us putting project manpower into.
> We don't need to do the not-terribly-portable stuff in the first
> round. For that, there could still be a bundled extension.
> The point is that UUIDs are nowhere near as usable as users have the
> right to expect, and we should fix that.
The reason that UUIDs aren't as usable as users "have a right to expect"
is that the underlying technology doesn't meet their (your) expectations.
Just because it's easy to imagine that there are universally unique
identifiers doesn't mean that there actually *are* universally unique
identifiers. There are only approximations with varying failure modes.
This is not our fault, and I don't want us to get caught up in trying
to fix a fundamentally broken concept --- which is what a generic
"uuidserial" API would be. If you try to paper over the difficulties
here, they'll just bite you on the rear someday.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-04-24 17:00:19 | Re: 9.4 Proposal: Initdb creates a single table |
Previous Message | Tom Lane | 2014-04-24 16:43:13 | Re: slow startup due to LWLockAssign() spinlock |