Re: [GENERAL] UUID's as primary keys

On Thu, Jun 29, 2006 at 02:40:15AM -0400, Greg Stark wrote:
> > Greg Stark <gsstark(at)mit(dot)edu> writes:
> > No, it doesn't, and we'd pay a nonzero price for allowing that.
> > Currently the executor doesn't have to care (much) about whether a
> > tuple is on-disk or in-memory --- the individual datums look the same
> > either way. Allowing them to be different would force a lot of
> > format conversion steps that currently need not happen.
>
> Is there ever a case where an entire tuple is passed around without knowing
> the typmod of an attribute in the tuple?

A tuple is just an array of datums, with some header information. The
problems come when you don't have a tuple anymore, but only the datum,
like in arguments for functions.

I think it's more a case that most places that deal with datums simply
don't know about typmods. For example, the return type of a function
can only be char, not char(16). If you consider the case of a function
returning a RAW, the caller will have no way of knowing the typmod,
they do know the type though.

To be honest, it seems like a lot of work to save the four bytes of
overhead for the varlena structure on disk if you're going to need it
in memory anyway. And anything like RAW(16) which people want for
UUIDs, if it's going to have a lot of functions associated with it, may
as well just be a new type.

I think time would be much better spent finding a way of allowing
user-defined types to be created without using C functions.

> The conversion would only really have to happen when the attribute is fetched
> or stored, not when the tuple is being passed around wholesale. But I have a
> feeling that would be more intrusive than just making the entire system typmod
> aware.

I'm not sure if tuples are ever passed wholesale very far. The first
node to actually do anything with it (any join, expression or condition
test) is going to need to deconstruct it. Consider where we currently we
have a "Filter Cond" on a "Seq Scan". Currently the filter can access
the datums directly on the disk page, with what you're proposing, it
can't.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.