Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)

> On Apr 29, 2020, at 1:09 AM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Tuesday, April 28, 2020, Rui DeSousa <rui(at)crazybean(dot)net <mailto:rui(at)crazybean(dot)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.