Re: (7.1) BIT datatype
От | Adriaan Joubert |
---|---|
Тема | Re: (7.1) BIT datatype |
Дата | |
Msg-id | 3A49F892.FAE2AED7@albourne.com обсуждение исходный текст |
Ответ на | RE: (7.1) BIT datatype ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | pgsql-hackers |
Christopher Kings-Lynne wrote: > > > Some SQL92 functionality is missing from the BIT and VARBIT types. > > > > It should be possible to enter hexadecimal values as: > > > > B'[<bit>...]'[{<separator>...'[<bit...]'}...] > > X'[<hexdigit>...]'[{<separator>...'[<hexdigit...]'}...] > > > > (Cannan and Otten: SQL - The Standard Handbook, p.38) > > > > but the hexadeximal form is not accepted. As Peter noted: the standard does not say whether X'..' should be a blob, a bit or a varbit type. Converting it into an integer seems to me to be the least reasonable solution, albeit the historical one, as larger bitmasks will not fit. With TOAST the bit type can contain quite large bit strings, so a case could be made for converting to bit (especially as the blob implementation has reputedly got some problems). > > I have been using the BIT and VARBIT types in Postgres 7.0.3 (undocumented I > believe), and I note that the _input_ format is as follows: > > update blah set flags='b101001'; -- Binary > update blah set flags='xff45'; -- Hex Yes, that was done due to limitations in the parser. These have been fixed and this format should not be used any longer. > > But the _output_ format (for varbit) is always: > > B'1010110' The SQL standard says nothing about the output of the BIT datatypes. The C-routines to interpret both the B'..' and X'..' formats, as well as output routines to generate both are implemented and included. The problem is that a default had to be chosen, and the B'..' format seemed more useful for people using small bit masks. I don't know whether a function was defined to return an X'..' string of a bit mask. I don't have one of the more recent Postgres snapshots down at the moment. Peter E. may know, as he did all the integration. An alternative may be to add a 'SET variable' to psql to govern the output format, but there seem to be too many of those already. Adriaan
В списке pgsql-hackers по дате отправления: