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