Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)

[Rui DeSousa <rui@xxxxxxxxxxxxx>]

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

On Tuesday, April 28, 2020, Rui DeSousa <rui@xxxxxxxxxxxxx> 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.