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

Kless wrote:<br /><blockquote cite="mid:e82ea310-cfd9-4b2e-9aec-4795f9073948@i76g2000hsf.googlegroups.com"
type="cite"><prewrap="">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. </pre></blockquote><br /> You are correct that putting widely used features into a standard that is
implementedby everyone is good.<br /><br /> This does not extend to the conclusion that one should never put in a
featureuntil it is standard. Look at any successful software product and see how it usually leads the standard rather
thanfollows it. People only tend to make standards once they realize things are getting out of control, which is long
afterthe products are in use.<br /><br /><blockquote
cite="mid:e82ea310-cfd9-4b2e-9aec-4795f9073948@i76g2000hsf.googlegroups.com"type="cite"><blockquote type="cite"><pre
wrap="">InPostgreSQL they're stored as 16 binary bytes [2], and the core
 
database does not include any function for generating UUIDs   </pre></blockquote><pre wrap="">
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. </pre></blockquote><br /> This is incorrect. UUID at 16 bytes is already "long" in terms of being used as
aprimary index. In an 8K page, one can only fit 512 UUIDs (forgetting the requirement for headers) - if it was stored
as32 bytes - or 36 bytes, or 40 bytes (with punctuation), it would be at less than 256 UUIDs per page. For a join table
joiningone set of UUID to another set, that's < 256 vs < 128. Doubling the size of an index row roughly doubles
thetime to look up the value.<br /><br /><blockquote
cite="mid:e82ea310-cfd9-4b2e-9aec-4795f9073948@i76g2000hsf.googlegroups.com"type="cite"><pre wrap="">I am not in favor
ofadding more database-specific types to ANY
 
database
- and I think PostGres doing it was a mistake. </pre></blockquote><br /> As somebody who wrote his own module to do
UUIDfor PostgreSQL when I needed it in PostgreSQL 8.0, I don't agree. Just as you think defining it in a standard is
betterthan each vendor doing it their own way, I think doing it in one product is better than each user of the product
doingit their own way.<br /><br /><blockquote
cite="mid:e82ea310-cfd9-4b2e-9aec-4795f9073948@i76g2000hsf.googlegroups.com"type="cite"><pre wrap="">If there is a
demandfor 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. </pre></blockquote><br /> Provide a real example of any similar product doing this. Exactly which
enhancementto a standard was defined without even a prototype existing used in an existing product that purports to
implementthe standard?<br /><br /> I'm sure one or two examples must exist, but I cannot think of any. Every
enhancementI can think of that eventually made it into a standard, was first implemented within a popular product, and
thendemanded as a standard to be applied to all other products.<br /><br /> Cheers,<br /> mark<br /><br /><pre
class="moz-signature"cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>