Re: uuid type for postgres

Hey Nathan.

I've started to make heavy use of pguuid. It had several bugs in it
that required fixing before I could use it. I have no preference on
pguuid. It was the only such PostgreSQL project I found that provided
a UUID type.

I'd be willing to work with you on ensuring that such a patch is in an
acceptable form for the core developers to accept, and help maintain
it.

My personal preference is that the type be called 'uuid' and accepted
into the core. Tom? Is their history on this issue?

Should it remain an extension, or can be get it built-in?

I find the UUID concept more useful than the SERIAL concept for data
that must now, or may in the future, be stored on multiple servers.
For example, submitting transactions to two different sites, where the
sites periodically synchronize up with each other, requiring a
relatively safe 'merge'. SERIAL can't do this at all. UUID can do
this as long as the rows are split into domains appropriately,
such as ensuring that unique column constraints do not need to
be enforced across sites.

UUID is also desirable over SERIAL for a unique identifier that will
be accessed from an outside source directly. Exposing the SERIAL
number to the outside isn't appealing for reasons including the
predictability of the sequence, the size of the database is exposed,
the internel implementation is exposed, and so on.

I suggest that UUID be recommended in place of SERIAL for certain
classes of applications, and that it therefore belongs in the core.
UUID and SERIAL can be used together (although, once you have a UUID,
it may not be useful to also have a SERIAL).

Ok, you can all tell me I'm wrong now... :-)

mark

On Tue, Sep 06, 2005 at 01:50:57PM +0000, nathan wagner wrote:
>
> I have been in need of a uuid type and ran across the pguuid download
> by Xiongjian (Mike) Wang. This wasn't really useful to me for two
> reasons: first, it is GPLed and I would prefer a more liberal license,
> secondly, it didn't compile cleanly on Mac OS 10.3, due to lack of a
> SIOCGETIFHWADDR (? i think, i can get the exact name if you want it)
> ioctl() under darwin.
>
> While I could dike out the code that calls it, that seems like a suboptimal
> solution. So after a bit of poking around the interweb i ran across
> Ralf Engelschall's ossp uuid library. This compiled with minimal
> effort on mac os. Some reading, and an evening later, i've made
> a server plugin with supporting SQL that implements an 'ossp_uuid'
> type.
>
> Now i have four questions:
>
> 1: Is it feasible for this to be included in the contrib section of
> the regular download? The uuid library is a "notice of copyright" style
> license, and I am willing to put my own code into the public domain.
>
> 2: Would just calling the type 'uuid' be better than 'ossp_uuid'? It's
> certainly a nicer name.
>
> 3: Would it be possible to include such a type as a postgres extension
> to the usual SQL types. It seems to me that having an officially
> supported type would be better than a user contributed type on the grounds
> that you could then rely on it being avaiable if postgres was.
> In particular, installing it as an extension would require the cooperation
> of the DBA, which may be infeasible in some environments.
>
> --
> Nathan Wagner
>

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