Re: Fwd: Proposal - UUID data type - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Fwd: Proposal - UUID data type
Date
Msg-id 877ibonuyk.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Fwd: Proposal - UUID data type  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: Fwd: Proposal - UUID data type  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Fwd: Proposal - UUID data type  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
"Mark Mielke" <mark@mark.mielke.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!


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: PATCH: CITEXT 2.0 v3
Next
From: Decibel!
Date:
Subject: Re: 8.1 index corruption woes