Re: length of string containing blanks is 0, || behaves differently than concat on string of blanks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: length of string containing blanks is 0, || behaves differently than concat on string of blanks
Дата
Msg-id 8666.1565961766@sss.pgh.pa.us
обсуждение исходный текст
Ответ на length of string containing blanks is 0, || behaves differently than concat on string of blanks  ("Ehrenreich, Sigrid" <Ehrenreich@consist.de>)
Ответы RE: length of string containing blanks is 0, || behaves differentlythan concat on string of blanks  ("Ehrenreich, Sigrid" <Ehrenreich@consist.de>)
Список pgsql-bugs
"Ehrenreich, Sigrid" <Ehrenreich@consist.de> writes:
> I am not sure, if this is a bug. I think at least it is a documentation bug.

The char(n) datatype has some odd rules: generally, trailing blanks are
considered insignificant, which is why you're getting 0 for the length.
Trailing blanks will also get stripped whenever the value is converted
to varchar or text, which is what's happening in your || example.
On the other hand, concat() doesn't execute any SQL type conversions;
it just concatenates the I/O representations of the values, so that
the trailing blanks survive.

Yes, all of these things are documented somewhere.  The implications
aren't always obvious of course.

Almost always, the correct response to questions like this is "don't
use char(n)".  The preferred string type in Postgres is text, or if
you have a reason to have a specific character-length limit (pro tip:
you probably don't), then use varchar(n).  In any case, if you think
trailing blanks are valid data, char(n) is not what to store them in.

            regards, tom lane



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

Предыдущее
От: "Ehrenreich, Sigrid"
Дата:
Сообщение: length of string containing blanks is 0, || behaves differently than concat on string of blanks
Следующее
От: "Ehrenreich, Sigrid"
Дата:
Сообщение: RE: length of string containing blanks is 0, || behaves differentlythan concat on string of blanks