The attached patch allows uuid_in() to parse a wider variety of
variant input formats for the UUID data type, per the TODO named in
the subject line.
Original discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01214.php
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01264.php
The original discussion left unresolved the question of what variant
input formats to accept. This patch takes the approach of allowing an
optional hyphen after each group of four hex digits. This will allow
4x-4x-4x-4x-4x-4x-4x-4x (the format that originally prompted the
discussion) as well as things like the Coldfusion format:,
8x-4x-4x-16x:
http://livedocs.adobe.com/coldfusion/6.1/htmldocs/functi54.htm
...and then there's this, which seems to be using 8x-8x-8x-8x:
http://lists.xensource.com/archives/html/xen-changelog/2005-11/msg00557.html
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.
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.
...Robert