On Fri, Jun 30, 2006 at 04:04:19AM -0400, mark@mark.mielke.cc wrote:
> > Martijn van Oosterhout 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.
> 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.
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 16make_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.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
