Re: Fwd: Proposal - UUID data type

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc>
Cc: "Kless" <jonas(dot)esp(at)googlemail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fwd: Proposal - UUID data type
Date: 2008-07-14 19:09:55
Message-ID: 877ibonuyk.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Mark Mielke" <mark(at)mark(dot)mielke(dot)cc> writes:

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

To be fair there are two types of standards. Some standards follow
implementations, others lead and prevent the babel of incompatible
implementations from ever developing. Both ways work in the right context.

But (perhaps unfortunately) the SQL spec is very definitely of the former
type. Nothing goes into the SQL spec that one of the implementors hasn't
already done.

But that said Postgres isn't one of the main participants in the spec
committee. We don't really want to add features that later get added to the
spec in an incompatible way and we have no say in the committee to avoid that
situation.

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

Really? It sounds like 100% difference to me. If you applied that logic to
everything you would have a database which runs at half the speed it would
otherwise.

Keep in mind also that your primary keys have to be stored in every other
table as foreign keys too...

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

C99? SMTP? NTP?

It tends to be important for network protocols since there's no gain in having
non-interoperable protocols.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-07-14 19:34:15 Re: Fwd: Proposal - UUID data type
Previous Message David E. Wheeler 2008-07-14 19:04:55 Re: PATCH: CITEXT 2.0 v3