> 1) Reduced error checking.
> 2) The '-' is not the only character that people have used. ClearCase uses
> '.' and ':' as punctuation.
> 3) People already have the option of translating the UUID from their
> application to a standard format.
> 4) As you find below, and is probably possible to improve on, a fixed
> format can be parsed more efficient.
Scenario 1. I have some standard format UUIDs and I want to parse
them. This change doesn't bother me at all because if I'm parsing
anywhere enough UUIDs for it to matter, the speed of my CPU, disk, and
memory subsystems will vastly outweigh the difference between the two
implementations. I measured the different between the two by running
them both in a tight loop on a fixed string. I challenge anyone to
produce a measurable performance distinction by issuing SQL queries.
I doubt that it is possible.
Scenario 2. I have some non-standard format UUIDs and I want to parse
them. This change helps me a lot, because I'm almost positive that
calling regexp_replace() and then uuid_in() is going to be MUCH slower
than just calling uuid_in(). And if I do that then my error checking
will be REALLY weak, unless I write a custom PL function to make sure
that dashes only occur where they're supposed to be, in which case it
will be even slower.
Scenario 3. I only want standard-format UUIDs to be accepted into my
database. Any non-standard format UUIDs should be rejected at parse
time. This change is pretty irritating, because now I have to use
regexp matching or something to make sure I've got the right format,
and it's going to be significantly slower.
My suspicion is that scenario 2 is a lot more common than scenario 3.
> I don't know which implementation was used for the PostgreSQL core, but any
> hard coded constants would allow for the optimizer to generate instructions
> that can run in parallel, or that are better aligned to machine words.
>
> 2-3% slow down for what gain? It still doesn't handle all cases, and it's
> less able to check the format for correctness.
This change is a long way from letting any old thing through as a
UUID. I'm sure there are lots of crazy ways to write UUIDs, but
everything I found with a quick Google search would be covered by this
patch, so I think that's pretty good. A key point for me is that it's
hard to imagine this patch accepting anything that was intended to be
something other than a UUID. (I am sure someone will now write back
and tell me about their favorite non-UUID thing that happens to have
32 hex digits with dashes for separators, but come on.)
...Robert