Re: patch: Allow the UUID type to accept non-standard formats

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Dawid Kuroczko" <qnex42(at)gmail(dot)com>
Cc: "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: Allow the UUID type to accept non-standard formats
Date: 2008-10-10 12:22:12
Message-ID: 603c8f070810100522v7df74a62vefb05487d9bc9c71@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-10-10 12:32:05 Re: Block nested loop join
Previous Message Robert Haas 2008-10-10 12:19:51 Re: patch: Allow the UUID type to accept non-standard formats