Robert Haas wrote:
> While we could perhaps accept only those variant formats which we
> specifically know someone to be using, it seems likely that people
> will keep moving those pesky dashes around, and we'll likely end up
> continuing to add more formats and arguing about which ones are widely
> enough used to deserve being on the list. So my vote is - as long as
> they don't put a dash in the middle of a group of four (aka a byte),
> just let it go.
>
I somewhat disagree with supporting other formats. Reasons include:
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.
> Somewhat to my surprise, this implementation appears to be about 2-3%
> slower than the one it replaces, as measured using a trivial test
> harness. I would have thought that eliminating a call to strlen() and
> an extra copy of the data would have actually picked up some speed,
> but it seems not. Any thoughts on the reason? In any case, I don't
> believe there's any possible use case where a 2-3% slowdown in
> uuid_to_string is actually perceptible to the user, since I had to
> call it 100 million times in a tight loop to measure it.
>
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.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>