Re: [HACKERS] Re: [GENERAL] Update of bitmask type
От | Adriaan Joubert |
---|---|
Тема | Re: [HACKERS] Re: [GENERAL] Update of bitmask type |
Дата | |
Msg-id | 37EB0AC6.C608E1A2@albourne.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [GENERAL] Update of bitmask type (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Re: [GENERAL] Update of bitmask type
|
Список | pgsql-hackers |
Hannu Krosing wrote: > > Adriaan Joubert wrote: > > > > b) seems to imply, rather bizarrely in my opinion, that > > > > B'001100' < B'10' > > > Maybe you start counting from the wrong end ? > > Just use them as you use char() > > 'AABBAA' < 'BA' > > Does it say something in the standard about direction, > is it left-> right or right->left ? No, not that I could find. But in the above example B'001100' < B'10' whichever end you start counting from, as 1>0. I have no particularly strong opinion on which way round it should be done -- perhaps we should just try to be consistent with other databases? Could somebody who has access to Oracle or Sybase please do a few tests and let me know? 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? I haven't quite understood what the variable attypmod is. In varchar.c it looks as if it is the length of the record, but if it is just an integer identifier, then I could store the exact length in there. In that case I could handle the difference between 3 and 5 bit strings correctly. My main worry was that this might be used in other routines to determine the length of a record. Adriaan
В списке pgsql-hackers по дате отправления: