From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Re: BIT/BIT VARYING status |
Date: | 2000-10-31 10:27:23 |
Message-ID: | Pine.LNX.4.21.0010310349350.777-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net http://yi.org/peter-e/
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-10-31 11:43:37 | Re: LIMIT in DECLARE CURSOR: request for comments |
Previous Message | Peter Eisentraut | 2000-10-31 09:57:01 | Re: Data definition for aclitem Datatype |