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)
|
| Список | 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 по дате отправления: