Re: Proposal for GUID datatype - Mailing list pgsql-hackers

From mark@mark.mielke.cc
Subject Re: Proposal for GUID datatype
Date
Msg-id 20060909122916.GA15725@mark.mielke.cc
Whole thread Raw
In response to Re: Proposal for GUID datatype  (Jan de Visser <jdevisser@digitalfairway.com>)
Responses Re: Proposal for GUID datatype  (mark@mark.mielke.cc)
List pgsql-hackers
On Sat, Sep 09, 2006 at 07:06:23AM -0400, Jan de Visser wrote:
> On Saturday 09 September 2006 01:33, mark@mark.mielke.cc wrote:
> > I don't think so. If it isn't 128 bits - and you want to fit it into
> > 128 bits, it means padding. Where should the padding go? As application
> > specific, it is up to the application to convert.
> I am not saying that. I am just saying that you shouldn't limit yourself to 
> any particular input formats. I understand that the example I gave is not a 
> full GUID. As I said, I use that result as a base for a 128 bit GUID.
> Aargh.

You say Aargh - but you still haven't explained what the parser would do.

It ignores punctuation - great - so now what? You provided a number that
used an odd number of hexadecimal characters, that was less than 128-bits
worth of data.

Exactly which 128-bit value would you expect it to represent? Where does
the padding go? The beginning? The end? Around the punctuation? When you
say you use it as a base - what do you mean, and may your intention match
the intention of anybody else who wishes to stuff a non-UUID into a UUID?

I'm not trying to be difficult - you never answered this, and it is a
decision that the software would need to make, if it were to do as you
suggest. I think it is improper, and that it is up to the application
to pad the non-128 bit value to 128-bits *before* passing it in -
although I still think this is invalid. What "version" of UUID are you
using?

Please don't answer again that you aren't saying something. Three
answers like this hasn't got us anywhere. Just tell me what 128-bit
value you think your original suggestion would represent (where should
the padding go?), and then justify why it should be a UUID at all.

Thanks,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/



pgsql-hackers by date:

Previous
From: Jan de Visser
Date:
Subject: Re: Proposal for GUID datatype
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Proposal for GUID datatype