On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] 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 16
(0 rows)
# select '1234FF'::uuid;
ERROR: Bad length for type 'uuid'
# select 'hello world'::uuid;
ERROR: Invalid characters for type 'uuid'
# select '1234567890abcdef'::uuid;
(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.

Attachment: signature.asc
Description: Digital signature

Reply via email to