>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
