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: 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 00:34:11
Message-ID: 87irmkvlz0.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > The input functions get it, the output functions (bpcharout,
> > bpcharsend, etc) don't. Which makes it kind of hard to print a raw
> > value if you don't know how long it's going to be. They used to, but
> > that was removed some time back.

> Even back then you couldn't rely on the typmod value to be supplied;
> it was quite likely to be passed as -1. The issue is not actually
> with on-disk storage, it is with function/operator arguments and
> results. Those have never been identified any more closely than by
> giving a type OID. So for any value that came from a function,
> you won't have a typmod, and you'd better be able to find out all
> you need to know just by inspecting the value itself. Hence, length
> words.

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.

> This is all pretty off-topic for pgsql-general, isn't it?

[moved to -hackers]

--
greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-06-29 03:23:17 Re: [GENERAL] UUID's as primary keys
Previous Message Bill Eaton 2006-06-28 21:35:37 Re: unusual "relation xxx does not exist" problem

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-06-29 00:43:23 Re: optimizing constant quals within outer joins
Previous Message Tom Lane 2006-06-29 00:08:21 Re: [HACKERS] Non-transactional pg_class, try 2