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 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.
> only tend to make standards once they realize things are getting out
> control, which is long after the products are in use.
Non-standard features just force people to stick with that one
In the long run, the only people who benefit are the product
>>> In PostgreSQL they're stored as 16 binary bytes , 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
> 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
> - or 36 bytes, or 40 bytes (with punctuation), it would be at less
> 256 UUIDs per page. For a join table joining one set of UUID to
> set, that's < 256 vs < 128. Doubling the size of an index row roughly
> doubles the time to look up the value.
Incorrect. Doubling the size of the index has very little effect on
long it takes to look up a value. Intelligent databases use a binary
search so doubling the size only means one additional comparison need
done. And heavily used indexes are generally cached in memory anyway.
>> I am not in favor of adding more database-specific types to ANY
>> - 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.
Fine. Whatever you want for your code. But don't expect the rest of
the world to jump because you want it.
>> 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
> enhancement to a standard was defined without even a prototype
> 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.
Most features added to the SQL standard, for instance. Like explicit
JOINs, recursive SQL and a bunch more. Also changes to the C++
such as exceptions were at least in the process of being evaluated and
approved before they were in any product.
There's a reason for having a process to propose features to a
And it does not require the proposed change to be in any product.
Remove the "x" from my email address
JDS Computer Training Corp.
In response to
pgsql-hackers by date
|Next:||From: Markus Wanner||Date: 2008-07-15 16:48:43|
|Subject: Postgres-R: current state of development|
|Previous:||From: Bruce Momjian||Date: 2008-07-15 15:03:55|
|Subject: Re: Core team statement on replication in