Re: [HACKERS] Re: [GENERAL] Update of bitmask type
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Re: [GENERAL] Update of bitmask type |
Дата | |
Msg-id | 37EB88E0.24A45661@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [GENERAL] Update of bitmask type (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Re: [GENERAL] Update of bitmask type
|
Список | pgsql-hackers |
> A second problem I encountered last night is that the postgres variable > length types only allow for the length of an array to be stored in > bytes. This means that the number of bits will automatically always be > rounded up to the nearest factor of 8, i.e. you want tp store 3 bits and > you get 8. For ordering and output this is not always going to produce > the correct output, as the bitstrings will get zero-padded. Is there > anywhere else where one could store the exact length of a bit string? attypmod has been modified recently to contain two fields (each of 16 bits) in a backward-compatible way. It can hold the size *and* precision of the numeric data types, and presumably should be used in a similar manner for your bit type. The problem is that you need another field which contains a length in bit units. Assuming that the second field in attypmod can't be used for this purpose, then istm that you will want to add a field to the data type itself. The character types have: length - total size of data, in bytes (4 bytes) data - body and you might have length - total size of data, in bytes (4 bytes) blen - total size of data, in bits (4 bytes) data - body - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: