Re: UUID's as primary keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Thomas Hallgren <thomas(at)tada(dot)se>, Psql_General <pgsql-general(at)postgresql(dot)org>
Subject: Re: UUID's as primary keys
Date: 2006-06-28 14:42:43
Message-ID: 15117.1151505763@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

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

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message A.M. 2006-06-28 14:43:26 Re: Null and Void() - Or,
Previous Message Andrew Gould 2006-06-28 14:36:07 Re: Null and Void() - Or, Abandon All Hope Ye Who allow

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-06-28 14:44:43 Re: Help with casting and comparing.
Previous Message Phil Frost 2006-06-28 14:35:37 optimizing constant quals within outer joins