Re: [GENERAL] UUID's as primary keys

On Thu, Jun 29, 2006 at 06:47:17PM +0200, Martijn van Oosterhout wrote:
> It seems to me that maybe the backend should include a 16-byte fixed
> length object (after all, we've got 1, 2, 4 and 8 bytes already) and
> then people can use that to build whatever they like, using domains,
> for example...

Sooooo... Back to this.

It won't happen unless somebody does it - and I realize that people
are busy with their own projects, so unless somebody more willing and
better suited will step up, I'm going to take a stab at getting
advanced consensus.

Please answer the below questions, and state whether your opinion is
just an opinion, or whether you are stating it as a PostgreSQL
maintainer and it is law. If you wish, you can rank preferences.

1) The added 128-bit type should take the form of:

a) UUID, with all functions
b) UUID, with only basic generation functions + encode/decode/indexable
c) UUID, with only encode/decode/indexable - generic except for the
name of the type, and the encoding format.
d) Generic 128-bit type - same as c) except may not encode or decode
as UUID (dashes). Either a large number (hex string?), or binary data.
e) Generic n-byte binary data type generator. Not sure of feasibility
of this at this point. See thread.

2) According to your answer in 1), the added 128-bit type should be:

a) In core first.
b) In contrib first.
c) In pgfoundry first.

Thanks,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/