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).
Close enough...
It does requires the reader to look into each constraint to know what’s going on.
And “n” is so informative...please. The name of the field tells me most of what I care about, the “n” and/or constraint are fluff.
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.
Not something I’m concerned about and if that other db doesn’t have something like TOAST it seems like an undesirable target.
David J.
