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