Re: 9.4 Proposal: Initdb creates a single table

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:35:18
Message-ID: 20140424163518.GA13261@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 24, 2014 at 11:30:15AM -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> > On 04/24/2014 04:57 PM, Tom Lane wrote:
> >> The reason why there's no generation function in core is that
> >> there is no standardized,
> >> guaranteed-to-produce-a-universally-unique-value generation
> >> algorithm. That was the reason for not putting something in core
> >> when the type was first created, and I do not see that the
> >> technology has advanced.
>
> > Why can't we implement all 5 variants from
> > http://en.wikipedia.org/wiki/Universally_unique_identifier and
> > just warn about the dangers in documentation ?
>
> 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.

> I wonder what it would take to adapt contrib/uuid-ossp to work on
> top of some other popular implementation of that code. We pretty
> much bet on the wrong horse when we picked the OSSP library to
> depend on, but otherwise I think the principle of using an external
> library was good.

So long as we can pick another horse later, sure.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-24 16:43:13 Re: slow startup due to LWLockAssign() spinlock
Previous Message Heikki Linnakangas 2014-04-24 16:33:49 Re: slow startup due to LWLockAssign() spinlock