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 87irmkvlz0.fsf@stark.xeocode.com
Whole thread Raw
Responses Re: [GENERAL] UUID's as primary keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Martijn van Oosterhout <kleptog@svana.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Instability in TRUNCATE regression test
Next
From: Greg Stark
Date:
Subject: Re: optimizing constant quals within outer joins