Re: [GENERAL] 'a' == 'a '
От | Chris Travers |
---|---|
Тема | Re: [GENERAL] 'a' == 'a ' |
Дата | |
Msg-id | 4357E774.5070601@travelamericas.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] 'a' == 'a ' ("Dann Corbit" <DCorbit@connx.com>) |
Ответы |
Re: [GENERAL] 'a' == 'a '
Re: [GENERAL] 'a' == 'a ' |
Список | pgsql-hackers |
Dann Corbit wrote: >Let me make something clear: >When we are talking about padding here it is only in the context of a >comparison operator and NOT having anything to do with storage. > > IIrc, varchar and bpchar are stored in a similar way, but are presented differently when retrieved. I.e. storage is separate from presentation in this case. I.e. the padding in bpchar occurs when it is presented and stripped when it is stored. Again, I am happy "solving" this simply by documenting it since any questions of interpretation and implimentation of the standard would be answered. So far what I (and I am sure others) have not heard is a strong case for changing the behavior, given that it is in line with a reasonable interpretation of the standards. >Given two strings of different in a comparison, most database systems >(by default) will blank pad the shorter string so that they are the same >length before performing the comparison. > > Understood, but what gain do you have in a case like this that might justify the effort that would go into making it, say, an initdb option? How often does this behavior cause problems? Best Wishes, Chris Travers Metatron Technology Consulting
В списке pgsql-hackers по дате отправления: