Re: Fwd: Proposal - UUID data type

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Kless <jonas(dot)esp(at)googlemail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fwd: Proposal - UUID data type
Date: 2008-07-14 18:07:49
Message-ID: 487B95F5.5080107@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kless wrote:
> 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 implemented by everyone is good.

This does not extend to the conclusion that one should never put in a
feature until it is standard. Look at any successful software product
and see how it usually leads the standard rather than follows it. People
only tend to make standards once they realize things are getting out of
control, which is long after the products are in use.

>> In PostgreSQL they're stored as 16 binary bytes [2], and the core
>> database does not include any function for generating UUIDs
>>
>
> 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.
>

This is incorrect. UUID at 16 bytes is already "long" in terms of being
used as a primary index. In an 8K page, one can only fit 512 UUIDs
(forgetting the requirement for headers) - if it was stored as 32 bytes
- or 36 bytes, or 40 bytes (with punctuation), it would be at less than
256 UUIDs per page. For a join table joining one set of UUID to another
set, that's < 256 vs < 128. Doubling the size of an index row roughly
doubles the time to look up the value.

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

As somebody who wrote his own module to do UUID for PostgreSQL when I
needed it in PostgreSQL 8.0, I don't agree. Just as you think defining
it in a standard is better than each vendor doing it their own way, I
think doing it in one product is better than each user of the product
doing it their own way.

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

Provide a real example of any similar product doing this. Exactly which
enhancement to a standard was defined without even a prototype existing
used in an existing product that purports to implement the standard?

I'm sure one or two examples must exist, but I cannot think of any.
Every enhancement I can think of that eventually made it into a
standard, was first implemented within a popular product, and then
demanded as a standard to be applied to all other products.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2008-07-14 18:10:02 Re: PATCH: CITEXT 2.0 v3
Previous Message Tom Lane 2008-07-14 18:06:52 Re: PATCH: CITEXT 2.0 v3