Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
Дата
Msg-id 101253.1691594772@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-bugs
David Rowley <dgrowleyml@gmail.com> writes:
> Anyway, 2004 was a long time ago. I can't imagine we could possibly
> make such a change today to put it back.

Yeah.  IMV, char(N) is a legacy type with legacy behaviors, and
we shouldn't change those behaviors for fear of breaking legacy
applications that might expect them.  If you don't like the way it
works, don't use char(N).

BTW, as far as the question of better optimization of fixed-width
fields goes, we couldn't do that anyway with char(N) except in the
ever-more-minority case of single-byte database encoding.  That's
because N is counted in characters not bytes (as is quite clear
from the SQL standard, even if their opinion about trailing spaces
is less clear).  I think that's a primary reason why nobody has
bothered to pursue such an optimization, and in turn that's why
char(N) is now such a backwater.

            regards, tom lane



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #18034: Accept the spelling "+infinity" in datetime input is not accurate