Re: 9.4 Proposal: Initdb creates a single table

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

In response to

Responses

Browse pgsql-hackers by date

  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