Re: [GENERAL] UUID's as primary keys
От | Greg Stark |
---|---|
Тема | Re: [GENERAL] UUID's as primary keys |
Дата | |
Msg-id | 87irmkvlz0.fsf@stark.xeocode.com обсуждение исходный текст |
Ответы |
Re: [GENERAL] UUID's as primary keys
|
Список | 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 по дате отправления: