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
|
Список | 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 по дате отправления: