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@mielke.cc / markm@ncf.ca / markm@nortel.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/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

mark@mark.mielke.cc writes:
> 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?

There is pretty much zero chance of being accepted into contrib, much
less core, if the code isn't pure BSD license. (We used to be a bit
lax about that, but are trying to clean things up.) Nathan's comment
about starting with code that was sorta-BSD-with-advertising alarmed me.

However, you can certainly set up a pgfoundry project with code of any
license you like. That would be a good starting point anyway --- at
some point you'd have to convince people that there's enough demand
for the feature to justify putting it in core, and being able to point
to X number of downloads from pgfoundry would go a long way towards
making that case.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, Sep 06, 2005 at 11:38:57AM -0400, tgl@sss.pgh.pa.us wrote:
>
> There is pretty much zero chance of being accepted into contrib, much
> less core, if the code isn't pure BSD license.

Hmm. Here is the copyright and license portion of the readme...

COPYRIGHT AND LICENSE

Copyright (c) 2004-2005 Ralf S. Engelschall <rse@engelschall.com>
Copyright (c) 2004-2005 The OSSP Project <http://www.ossp.org/>

This file is part of OSSP uuid, a library for the generation
of UUIDs which can found at http://www.ossp.org/pkg/lib/uuid/

Permission to use, copy, modify, and distribute this software for
any purpose with or without fee is hereby granted, provided that
the above copyright notice and this permission notice appear in all
copies.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

Reading the postgres license from the faq...

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group Portions
Copyright (c) 1994-1996 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement is
hereby granted, provided that the above copyright notice and this paragraph and
the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST
PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF
THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND
THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

These two licenses appear to be functionally identical. Both require
notice of the copyright to be included, and both allow use for any purpose.
The wording of the requirement is even nearly identical.

By way of disclaimer, I am not (yet) an attorney.

> (We used to be a bit
> lax about that, but are trying to clean things up.) Nathan's comment
> about starting with code that was sorta-BSD-with-advertising alarmed me.

Perhaps i was a bit lax in my wording. I don't read the license
as requiring any advertising at run time, just as a requirement that
the copyright notice be kept with the source code. That is, an
identical requirement to the one that postgres itself uses.

--
Nathan Wagner

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Mark,

> 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).

I think that, if you want to push a refactored UUID type for PostgreSQL
8.2, that you'd better separate your database design arguments from your
inclusion arguments.

For example, you might get my agreement that it would be useful to have a
UUID as a core type; you would *never* get my agreement to recommend using
UUID to newbies. I have seen *far* too many abuses of UUIDs in really
bad database design. People who use them should be experienced enough to
know what they're doing.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

I agree with Josh on the UUID type, it gets abused far too often and (IMHO)
isn't widely enough used to belong in the core. Couldn't you just fix the
problem in pguuid rather than write a whole new type?

On 9/6/05, Josh Berkus <josh@agliodbs.com> wrote:
>
> Mark,
>
> > 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).
>
> I think that, if you want to push a refactored UUID type for PostgreSQL
> 8.2, that you'd better separate your database design arguments from your
> inclusion arguments.
>
> For example, you might get my agreement that it would be useful to have a
> UUID as a core type; you would *never* get my agreement to recommend using
> UUID to newbies. I have seen *far* too many abuses of UUIDs in really
> bad database design. People who use them should be experienced enough to
> know what they're doing.
>
> --
> --Josh
>
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

On Tue, Sep 06, 2005 at 03:57:55PM -0400, jonah.harris@gmail.com wrote:
> I agree with Josh on the UUID type, it gets abused far too often

Out of curiosity, how does it get abused? It doesn't seem to me
that it would be any more prone to abuse than any other type.

> and (IMHO) isn't widely enough used to belong in the core.

Seems like a self-fulfilling cycle. There isn't one in core
or contrib (pguuid is not in contrib, IIRC), and so one doesn't
get used. Since no one uses one, it's not in core or contrib.

> Couldn't you just fix the
> problem in pguuid rather than write a whole new type?

Not sure which you you're addressing here, but I can't fix the license
problem. Nor can I readily fix the lack of a mac ioctl() to get
the hardware mac address.

In any case, from an economy of effort view, I'd much rather maintain
a postgres extension/interface to an existing uuid library, than fret
the details of writing a uuid library myself. UUIDs themselves don't
really interest me, I just happen to need one for my application.

I'm basically done. I'll tar it up and post a link to an alpha version in a
couple of hours. As far as i can tell, it works fine. I'm calling it alpha
because i'm not doing proper error checking, and i'm not sure how to log or
throw an error even if i detect one. Also, I have only compiled it on
Mac OS 10.3, I'll want to test it on my linux box.

--
Nathan Wagner

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sep 6, 2005, at 12:57 PM, Jonah H. Harris wrote:

> On 9/6/05, Josh Berkus <josh@agliodbs.com> wrote:
> Mark,
>
> > 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).
>
> I think that, if you want to push a refactored UUID type for
> PostgreSQL
> 8.2, that you'd better separate your database design arguments from
> your
> inclusion arguments.
>
> For example, you might get my agreement that it would be useful to
> have a
> UUID as a core type; you would *never* get my agreement to
> recommend using
> UUID to newbies. I have seen *far* too many abuses of UUIDs in
> really
> bad database design. People who use them should be experienced
> enough to
> know what they're doing.
>
> I agree with Josh on the UUID type, it gets abused far too often
> and (IMHO) isn't widely enough used to belong in the core.
> Couldn't you just fix the problem in pguuid rather than write a
> whole new type?
>

This sounds like a strawman argument. People abuse a lot of types to
do a lot of things they shouldn't be doing, adding types to the core
isn't really going to change that much one way or the other.

If the documentation gives the user a good idea of when to use UUID
and when not, I think it would be a good addition. Worst case, it
could become part of contrib, so at least it ships with PostgreSQL
with the same license. The GPL license of pguuid is a show-stopper
for some (and seems like a silly choice for what it is and who it's
for).

-bob

The only time I've seen someone use UUIDs in PostgreSQL is when they were
converting from SQL Server. I've seen many bad data models using UUID that
could've/should've used normal sequences for portability.

I look forward to seeing you're code.

Thanks!


On 9/6/05, nathan wagner <nw@hydaspes.if.org> wrote:
>
> On Tue, Sep 06, 2005 at 03:57:55PM -0400, jonah.harris@gmail.com wrote:
> > I agree with Josh on the UUID type, it gets abused far too often
>
> Out of curiosity, how does it get abused? It doesn't seem to me
> that it would be any more prone to abuse than any other type.
>
> > and (IMHO) isn't widely enough used to belong in the core.
>
> Seems like a self-fulfilling cycle. There isn't one in core
> or contrib (pguuid is not in contrib, IIRC), and so one doesn't
> get used. Since no one uses one, it's not in core or contrib.
>
> > Couldn't you just fix the
> > problem in pguuid rather than write a whole new type?
>
> Not sure which you you're addressing here, but I can't fix the license
> problem. Nor can I readily fix the lack of a mac ioctl() to get
> the hardware mac address.
>
> In any case, from an economy of effort view, I'd much rather maintain
> a postgres extension/interface to an existing uuid library, than fret
> the details of writing a uuid library myself. UUIDs themselves don't
> really interest me, I just happen to need one for my application.
>
> I'm basically done. I'll tar it up and post a link to an alpha version in
> a
> couple of hours. As far as i can tell, it works fine. I'm calling it alpha
> because i'm not doing proper error checking, and i'm not sure how to log
> or
> throw an error even if i detect one. Also, I have only compiled it on
> Mac OS 10.3, I'll want to test it on my linux box.
>
> --
> Nathan Wagner
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

On Tue, Sep 06, 2005 at 09:16:13PM +0000, nathan wagner wrote:
> On Tue, Sep 06, 2005 at 03:57:55PM -0400, jonah.harris@gmail.com wrote:
> > I agree with Josh on the UUID type, it gets abused far too often
>
> Out of curiosity, how does it get abused? It doesn't seem to me
> that it would be any more prone to abuse than any other type.

A typical abuse, as I have seen it, is for OO coders on the front-end
to turn the entire databse into what amounts to an associative array.
It then becomes somewhere between difficult and impossible to get good
performance, as UUID is the only thing useful as a PK/FK.

> > and (IMHO) isn't widely enough used to belong in the core.
>
> Seems like a self-fulfilling cycle. There isn't one in core or
> contrib (pguuid is not in contrib, IIRC), and so one doesn't get
> used. Since no one uses one, it's not in core or contrib.

In this case, not having it easy to get to is, IMHO, an *excellent*
idea. The whole thing is a giant foot-gun.

Just my $.02.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend