Re: UUID's as primary keys
| От | Thomas Hallgren | 
|---|---|
| Тема | Re: UUID's as primary keys | 
| Дата | |
| Msg-id | 44A253FC.3010409@tada.se обсуждение исходный текст  | 
		
| Ответ на | Re: UUID's as primary keys (Martijn van Oosterhout <kleptog@svana.org>) | 
| Ответы | 
                	
            		Re: UUID's as primary keys
            		
            		 | 
		
| Список | pgsql-general | 
Martijn van Oosterhout wrote: > On Wed, Jun 28, 2006 at 10:22:45AM +0200, Thomas Hallgren wrote: >> Thanks. That would of course work but at the same time it increases the >> complexity of my app. Yet another component to install and keep track >> of. It's also a bit of an overkill since the only thing I need is an >> opaque bit storage. Why is it that PostgreSQL lack a fixed length binary >> type similar to the RAW type in Oracle? ISTM that could be very useful >> and not very hard to implement. > > AIUI, it can't be done because of a basic rule of the type system: the > typmod can't be necessary to interpret the binary representation of a > value. For something like RAW(16) the type would be the oid for "raw" > and the typmod would be 16. However, when reading the value from a disk > page, you're not given the typmod, so you have no way of determining > the length. > OK. I thought you always had a type descriptor handy when reading the binary representation. I've noticed that the typmod is expected in some receive functions (bpcharrecv and numeric_recv for instance). Are you saying that there are times when you don't use that? Regards, Thomas Hallgren
В списке pgsql-general по дате отправления: