Fwd: Proposal - UUID data type

---------- Forwarded message ----------
From: Jerry Stuckle <jstuck...@attglobal.net>
Date: Jul 13, 10:29 pm
Subject: Proposal - UUID data type
To: comp.databases.mysql


Kless wrote:
> On Jul 13, 9:37 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Rather, I would think you should propose the UUID data type be added to
>> the SQL standard.  There are enough variations from the standards now.
> Those variations must be managed by the language and not by the RDBMS,
> where its *main work* is  storing data using the specific data types.
> A lot of languages already have modules to working with UUID [1].

Yes, they must be managed by the language.  Which is why it should be
part of the standard.  That way, changing databases does not require
changing code.

>> And as it is, UUID's can be stored as a 32 byte string.  So it isn't as
>> if there is not an alternative.
> If they're stored in ASCII form (32 hex digits), would indeed be very
> inefficient. So it's necessary that the RDBMS have a specific data
> type to handle the UUIDs.

> In PostgreSQL they're stored as 16 binary bytes [2], and the core
> database does not include any function for generating UUIDs

> [1]http://en.wikipedia.org/wiki/Uuid#Implementations
> [2]http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/...

Yep, which in the grand scheme of things, probably makes zero
difference.  The difference between 16 and 32 bytes in any single row
is
minuscule.

I am not in favor of adding more database-specific types to ANY
database
- and I think PostGres doing it was a mistake.

If there is a demand for it, then it should be added to the SQL
standard.  That is the correct way to propose a change.  That's why
there are standards.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================