Skip site navigation (1) Skip section navigation (2)

Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: Kenneth Marshall <ktm(at)rice(dot)edu>, Zeugswetter Andreas ADI SD <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Date: 2008-02-28 23:45:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
James Mansion wrote:
> Kenneth Marshall wrote:
>> conversion process themselves. Accepting random input puts a performance
>> hit on everybody following the standard.
> Why is that necessarily the case?
> Why not have a liberal parser and a configurable switch that 
> determines whether non-standard
> forms are liberally accepted, accepted with a logged warning, or 
> rejected?

I recall there being a measurable performance difference between the 
most liberal parser, and the most optimized parser, back when I wrote 
one for PostgreSQL. I don't know how good the one in use for PostgreSQL 
8.3 is. As to whether the cost is noticeable to people or not - that 
depends on what they are doing. The problem is that a UUID is pretty 
big, and parsing it liberally means a loop.

My personal opinion is that this is entirely a philosophical issue, and 
that both sides have merits. There is no reason for PostgreSQL to 
support all formats, not matter how non-standard, for every single type. 
So, why would UUID be special? Because it's easy to do is not 
necessarily a good reason. But then, it's not a bad reason either.


Mark Mielke <mark(at)mielke(dot)cc>

In response to


pgsql-hackers by date

Next:From: James MansionDate: 2008-02-29 00:07:33
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Previous:From: James MansionDate: 2008-02-28 23:27:37
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group