Re: Re: BIT/BIT VARYING status - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Re: BIT/BIT VARYING status
Date
Msg-id Pine.LNX.4.21.0010310349350.777-100000@peter.localdomain
Whole thread Raw
In response to Re: BIT/BIT VARYING status  (Adriaan Joubert <a.joubert@albourne.com>)
List pgsql-hackers
Adriaan Joubert writes:

> > 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.

I have gotten the B'1001'-style syntax to work, but the zpbit_in function
rejects the input.  You need to change the *_in functions to accept input
in the form of a string of only 1's and 0's.  Also, the output functions
should print 1's and 0's.

I'm somewhat confused about the <hex string>s; according to the standard
they might also be a BLOB literal.  I'd say we get the binary version
working first, and then wonder about this.

> Also, it the parser did not seem to be too happy about the 'position'
> syntax,

The parser converted 'position(a in b)' into 'strpos(b, a)'.  I changed it
so it converts it into 'position(b, a)' and aliased the other functions
appropriately.  I changed the order of your arguments for that.

> I noticed that the substring syntax does not seem to work:

Similar issue as above.  Should work now.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Data definition for aclitem Datatype
Next
From: Philip Warner
Date:
Subject: Re: LIMIT in DECLARE CURSOR: request for comments