Re: Fixed length datatypes. WAS [GENERAL] UUID's as - Mailing list pgsql-hackers

On Fri, Jun 30, 2006 at 10:38:49AM +0200, Martijn van Oosterhout wrote:
> On Fri, Jun 30, 2006 at 04:04:19AM -0400, mark@mark.mielke.cc wrote:
> > > > It seems to me that maybe the backend should include a 16-byte fixed
> > > > length object (after all, we've got 1, 2, 4 and 8 bytes already) and
> > > > then people can use that to build whatever they like, using domains,
> > > > for example...
> > > So how about the split? I.e. just add a 16 byte data type and forget all 
> > > about UUID's for now.
> > Martijn: Were you thinking that it would look like a really big integer,
> > displayed by default as a decimal string in the client?
> > This makes sense to me.
> Either that, or a hex string. My problem with displaying as integer is
> that not many clients will be able to parse (or print) a 16-byte
> integer (the C library doesn't do it), but anyone can write a
> hex-to-binary converter, or convince scanf/printf to do it for them.

No real preference here. I'd be happy to have a native 16-byte type.

> > If it was a full data type - could it be passed around in memory by
> > value, and not as a pointer? Or is 16 bytes too big to pass around by
> > value?
> You can't pass it by value (doesn't fit in a register on the CPU and
> there is no corrosponding C type), and I'm not sure you'd want to. A
> pointer is much easier and faster to pass around.

It depends how it is used. If the memory location needs to be
allocated, for the value to be used only a few times, the overhead of
allocation and redirection can be more expensive. If many though, than
the reduction in value copying can make the pointer faster. 64-bytes,
and 128-bytes are just on the line of not being clearly one or the
other. It was just a thought though. The PostgreSQL API seemed pretty
fixed the last time I looked at this stuff.

> The other thing I was thinking of is a type generator, like so:
> # select make_raw_hex_type(16,'uuid');
> NOTICE: Created raw hex type 'uuid' of fixed length 16
>  make_raw_hex_type
> -------------------
> (0 rows)
> # select '1234FF'::uuid;
> ERROR: Bad length for type 'uuid'
> # select 'hello world'::uuid;
> ERROR: Invalid characters for type 'uuid'
> # select '1234567890abcdef'::uuid;
>      ?column?
> ------------------
>  1234567890ABCDEF
> (1 row)

> Only this could be used to create other types too, for cryptographic
> functions for example. PostgreSQL doesn't have any type generators yet,
> so I'm unsure whether a patch creating one would be accepted for core.

Not sure what I think of this. I suppose the intention would be for it
to work for lengths other than 16? I can see people wanting to use such
a generalized function for char as well as bytea, for at least latin1
characters...

If people agree to a generic 16-byte type, or a hex type with defined
fixed length with a set of standard functions and index operators that
it should work for, but nobody more qualified wants to make the patch
- I'll step up.

Cheers,
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/