Re: Fixed length datatypes. WAS [GENERAL] UUID's as

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(at)mark(dot)mielke(dot)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(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)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 bind them...

http://mark.mielke.cc/