Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)

Поиск
Список
Период
Сортировка
От Rui DeSousa
Тема Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Дата
Msg-id 1F5812EC-881C-4531-B16E-3B5C92BA3586@crazybean.net
обсуждение исходный текст
Ответ на Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-admin


On Apr 29, 2020, at 1:09 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Tuesday, April 28, 2020, Rui DeSousa <rui@crazybean.net> wrote:
Don’t fool yourself, you are not future proofing your application; what really is happening is a slow creeping data quality issue which later needs a special project just clean up.

I don’t use text instead of varchar(n) for future proofing and use it quite well within well defined relational schemas.  Using varchar(n) in a table always has a better solution, use text and a constraint.

David J.

I would agree with you that "text and a constraint" is a lot better than just text; and would be functionally equivalent to varchar(n).

It does requires the reader to look into each constraint to know what’s going on.

Also, when porting the schema to a different database engine and the create table statement fails because it’s too wide and doesn’t fit on a page; the end result is having to go back and redefine the text fields as varchar(n)/char(n) anyway.

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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Следующее
От: Tim Cross
Дата:
Сообщение: Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)