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 14:12:15 |
Message-ID: | Pine.LNX.4.21.0010311505280.1073-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Adriaan Joubert writes:
> Peter, I think it is a problem if the B or X are dropped from the input,
> as that is the only way to determine whether it is a binary or hex
> string.
Well, you just assume it's a binary string, because it's unclear as of yet
whether you're going to get to handle hex strings at all. However, I
changed the scanner to include a leading 'b', so now it works:
peter=# select B'1001';
?column?
----------
X9
(1 row)
peter=# select B'1001' | b'11';
?column?
----------
XC
(1 row)
The output definitely ought to be in binary though ("b1001").
You also might want to make the leading 'b' optional because this seems
confusing:
peter=# select cast ('1001' as bit);
ERROR: zpbit_in: 1001 is not a valid bitstring
> Also, on output, shouldn't we poduce B'xxxx' and X'yyyyy' to conform
> with the input strings?
If you did that, then your input function has to be prepared for values
like "B'1001'". (Think copy out/copy in.) I think the above plan should
work okay.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Perchine | 2000-10-31 14:16:29 | Problem with 2 avcuums in parallel |
Previous Message | Philip Warner | 2000-10-31 13:23:53 | Re: AW: LIMIT in DECLARE CURSOR: request for comments |