Re: UUID generation functions

Please see my comments in line.

> -----Original Message-----
> From: pgsql-admin-owner(at)postgresql(dot)org [mailto:pgsql-admin-
> owner(at)postgresql(dot)org] On Behalf Of Milen A. Radev
> Sent: Monday, June 02, 2008 6:24 PM
> To: pgsql-admin(at)postgresql(dot)org
> Subject: Re: [ADMIN] UUID generation functions
>
> Milen A. Radev написа:
> > John DeSoi написа:
> >>
> >> On Jun 2, 2008, at 3:19 PM, Kevin Grittner wrote:
> >>
> >>> Any chance of going to 8.3?
> >>>
> >>> http://www.postgresql.org/docs/8.3/interactive/datatype-uuid.html
> >>
> >> But 8.3 still does not generate UUIDs, only stores/compares them. From
> >> the link above:
> >>
> >>> PostgreSQL provides storage and comparison functions for UUIDs, but
> >>> the core database does not include any function for generating UUIDs,
> >>> because no single algorithm is well suited for every application.

As far as I can see, there are really only 2 types, either time-based or random. I guess a third "type" could be one where 2 long integers are used to "generate" the UUID.

Would this really add that much code? I haven't yet implemented such algorithms to know - I've simply used the underlying systems services when I needed UUIDs.

> >>
> >> For reasons mentioned by the other poster, it would be helpful if
> >> PostgreSQL could generate them. Is there really more than 2 or 3
> >> needed options where it would be huge code bloat to include sufficient
> >> alternatives?
> >
> > http://www.postgresql.org/docs/8.3/static/uuid-ossp.html
>
> My bad - just realised the OP most probably needs a Windows-compatible
> solution and uuid-ossp is not.
>

Actually, I'm developing on Windows, but deploying on Linux (both the web-server and the DB server), so a solution that is independent of platform is the most desirable. I was hoping that PG would have something to generate UUIDs internally.

If PG doesn't have the ability to generate UUIDs, I'll put the code in the web-server (tomcat) to do so. I was hoping to have this functionality as close as possible to the persistence of the data (where rules of uniqueness and integrity can be more easily enforced).

Gord

>
> --
> Milen A. Radev
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin