I'm sorry, but it was necessary that certain answers were answered by
someone with wide knowledge on databases and overall about its own
database. This one was the only way, and I believe that it has been
enough positive, at least for the end users -every one that choose its
data base-. At least th
An answer of Jerry Stuckle:
---
>> 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.
> You are correct that putting widely used features into a standard that
> is impl
am, [EMAIL PROTECTED] (Martijn van Oosterhout) wrote:
> On Mon, Jul 14, 2008 at 01:04:33AM -0700, Kless wrote:
> > I am not in favor of adding more database-specific types to ANY
> > database
> > - and I think PostGres doing it was a mistake.
>
> So you think that ad
-- Forwarded message --
From: Jerry Stuckle <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> wrote:
>> Rather, I would think you sh
d now - why does
> > PostgreSQL define UUID_LEN as 16?
>
> > I will investigate if I have time tonight. There MUST be some mistake
> > or misunderstanding. 128-bit numbers should be stored as 8 bytes, not 16.
>
> G Kless you've confused me. 32-bit numbers =
The new data type, UUID, is stored as a string -char(16)-:
struct pg_uuid_t
{
unsigned char data[UUID_LEN];
};
#define UUID_LEN 16
but this it's very inefficient as you can read here [1].
The ideal would be use bit(128), but today isn't possible. One
possible so
