Re: Fwd: Proposal - UUID data type

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Fwd: Proposal - UUID data type
Дата
Msg-id 877ibonuyk.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Fwd: Proposal - UUID data type  (Mark Mielke <mark@mark.mielke.cc>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: PATCH: CITEXT 2.0 v3
Следующее
От: Decibel!
Дата:
Сообщение: Re: 8.1 index corruption woes