Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] UUID's as primary keys

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Thomas Hallgren <thomas(at)tada(dot)se>, Psql_General <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] UUID's as primary keys
Date: 2006-06-29 06:40:15
Message-ID: 87y7vgtqgg.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Thomas HallgrenDate: 2006-06-29 07:02:38
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: J. Andrew RogersDate: 2006-06-29 06:21:08
Subject: Re: Fixed length datatypes.

pgsql-general by date

Next:From: Thomas HallgrenDate: 2006-06-29 07:02:38
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: J. Andrew RogersDate: 2006-06-29 06:21:08
Subject: Re: Fixed length datatypes.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group