Re: BIT/BIT VARYING status

Tom Lane wrote:
> 
> I have made a first cut at completing integration of Adriaan Joubert's
> BIT code into the backend.  There are a couple little things left to
> do (for example, scalarltsel doesn't know what to do with BIT values)
> as well as some not-so-little things:
> 
> 1. SQL92 mentions a bitwise position function, which we do not have.

Sorry, I have been very busy, so only got down to implementing a
position function last night. It's a bit messy (lots of masks and
bit-twiddling), but I feel fairly happy now that it is doing the right
thing. I tested it with my own loadable types, as the integration into
postgres proper stumped my somewhat. The next oid up for a bit function
is in use already. Anyway, the patches are attached, and I'm hoping that
some friendly sole will integrate the new position function into
postgres proper.
 
> 2. We don't handle <bit string> and <hex string> literals correctly;
> the scanner converts them into integers which seems quite at variance
> with the spec's semantics.

This is still a problem that needs to be fixed. Also, it the parser did
not seem to be too happy about the 'position' syntax, but I may have it
wrong of course. I don;t know how to attach the position function to a
piece of syntax such as (position <substr> in <field>) either, so I'm
hoping that somebody can pick this up.

Also, i have started putting together a file for regression testing. I
noticed that the substring syntax does not seem to work:

SELECT SUBSTRING(b FROM 2 FOR 4)
       FROM ZPBIT_TABLE;

gives:

ERROR:  Function 'substr(bit, int4, int4)' does not exist
        Unable to identify a function that satisfies the given argument
types
        You may need to add explicit typecasts

and similar for a varying bit argument.

If somebody with better knowledge of postgres could do the integration,
please, I will finish off a regression test.

Thanks!

Adriaan