>> 3) People already have the option of translating the UUID from their
>> application to a standard format.
>
> Regexp, the swiss-army knife of data manipulation. ;)
>
> While possible, it really is not that easy and efficient. At least we should
> accept dashless UUIDs, so instead of tediously reformatting UUID once
> could do s/-//g
We actually already do accept that.
>> 4) As you find below, and is probably possible to improve on, a fixed
>> format can be parsed more efficient.
>
> What I was thinking about is using the same lookup-table style approach
> as encode()/decode() pair uses. Should be faster than current implementation,
> and skipping over '-' (and even ':' or '.') is even simpler. I don't
> know internals
> good enough to know how that would work in encodings like UTF16...
>
> See http://doxygen.postgresql.org/encode_8c-source.html#l00107
I thought about this, but it's sort of not worth it. We're talking
about a function that already executes in something on the order of a
microsecond. Shaving another 10% off isn't going to help anyone.
...Robert