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
> 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)
ERROR: Function 'substr(bit, int4, int4)' does not exist
Unable to identify a function that satisfies the given argument
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.
In response to
pgsql-hackers by date
|Next:||From: Zeugswetter Andreas SB||Date: 2000-10-30 08:34:03|
|Subject: AW: LIMIT in DECLARE CURSOR: request for comments|
|Previous:||From: ishii||Date: 2000-10-30 07:17:31|
|Subject: pgsql (configure.in)|