Re: Re: BIT/BIT VARYING status
| От | Peter Eisentraut | 
|---|---|
| Тема | Re: Re: BIT/BIT VARYING status | 
| Дата | |
| Msg-id | Pine.LNX.4.21.0010311505280.1073-100000@peter.localdomain обсуждение исходный текст  | 
		
| Ответ на | Re: Re: BIT/BIT VARYING status (Adriaan Joubert <a.joubert@albourne.com>) | 
| Список | 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@gmx.net       http://yi.org/peter-e/
		
	В списке pgsql-hackers по дате отправления: