Re: [HACKERS] Re: [GENERAL] Update of bitmask type - Mailing list pgsql-hackers

From Adriaan Joubert
Subject Re: [HACKERS] Re: [GENERAL] Update of bitmask type
Date
Msg-id 37EB0AC6.C608E1A2@albourne.com
Whole thread Raw
In response to Re: [HACKERS] Re: [GENERAL] Update of bitmask type  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: [HACKERS] Re: [GENERAL] Update of bitmask type  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Michael Simms
Date:
Subject: Re: [HACKERS] Frustration
Next
From: Tatsuo Ishii
Date:
Subject: int8 and index