Re: FW: BUG #17258: Unexpected results in CHAR(1) data type

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: FW: BUG #17258: Unexpected results in CHAR(1) data type
Дата
Msg-id CAKFQuwYOB7u_OA41sVCjgmYsOb=BqjRXX6bz1TdpJ=NECa-7cA@mail.gmail.com
обсуждение исходный текст
Ответ на FW: BUG #17258: Unexpected results in CHAR(1) data type  ("David M. Calascibetta" <david@calascibetta.com>)
Ответы RE: FW: BUG #17258: Unexpected results in CHAR(1) data type  ("David M. Calascibetta" <david@calascibetta.com>)
Список pgsql-bugs
Дерево обсуждения
On Fri, Oct 29, 2021 at 1:17 PM David M. Calascibetta <david@calascibetta.com> wrote:

Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type

Ok, but my example was just a simplified version of what is going on.
The actual problem stems from a CHAR(1) column data type that is behaving the same way.
I was just trying to create a super-simple example of the problem.
It still seems to me that a CHAR(1) should never be zero length, regardless of how it's implemented.


This qualifies as a feature request, not a bug.  One could write a version of substr that does what you expect (it probably wouldn't be named substr though) and takes in a character data type.  It's just no one has, nor is likely to.  Thus you are stuck using versions that take in text and you get the char-to-text casting side effects.

If you do octet_length(' ':: character(1)) it will return 1, not zero.  So it indeed has a length one.

David J.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #17245: Index corruption involving deduplicated entries
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #17245: Index corruption involving deduplicated entries