Re: [GENERAL] UUID's as primary keys - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [GENERAL] UUID's as primary keys
Date
Msg-id 87y7vgtqgg.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: [GENERAL] UUID's as primary keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] UUID's as primary keys  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > Hm, so it could be stored on disk without the length header as long as
> > the length header is added to the in-memory representation? I don't
> > think the type system has hooks for reading and storing data to disk
> > though.
> 
> 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?

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.

-- 
greg



pgsql-hackers by date:

Previous
From: "J. Andrew Rogers"
Date:
Subject: Re: Fixed length datatypes.
Next
From: Thomas Hallgren
Date:
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as