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. > People > only tend to make standards once they realize things are getting out > of > control, which is long after the products are in use. Non-standard features just force people to stick with that one product. In the long run, the only people who benefit are the product developers. >>> 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. Incorrect. Doubling the size of the index has very little effect on how long it takes to look up a value. Intelligent databases use a binary search so doubling the size only means one additional comparison need be done. And heavily used indexes are generally cached in memory anyway. >> 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. 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 > 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. Most features added to the SQL standard, for instance. Like explicit JOINs, recursive SQL and a bunch more. Also changes to the C++ standard 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 product. And it does not require the proposed change to be in any product. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. [EMAIL PROTECTED] ================== ----------------------- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
