Re: Re: BIT/BIT VARYING status

Поиск
Список
Период
Сортировка
От Adriaan Joubert
Тема Re: Re: BIT/BIT VARYING status
Дата
Msg-id 39FEB246.A4467197@albourne.com
обсуждение исходный текст
Ответ на Re: Re: BIT/BIT VARYING status  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Re: BIT/BIT VARYING status  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut wrote:
> 
> 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.

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. Isn't it possible to just remove the quotes, or even do nothing?
The current code expects a string of the form  Bxxxxx  or Xyyyyy. If the
quotes are left in, I can easily modify the code, but guessing whether
the string 1001 is hex or binary is an issue, and I seem to recall that
the SQL standard requires both to be valid input.

Also, on output, shouldn't we poduce B'xxxx' and X'yyyyy' to conform
with the input strings?

Adriaan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: LIMIT in DECLARE CURSOR: request for comments
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: LIMIT in DECLARE CURSOR: request for comments