Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length) - Mailing list pgsql-admin

From David G. Johnston
Subject Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Date
Msg-id CAKFQuwaQ3Wxbqgs6es6Rh8NO9Ugn8VEUNMPjoErCX17a2wY51w@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)  (Rui DeSousa <rui@crazybean.net>)
Responses Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)  (Rui DeSousa <rui@crazybean.net>)
List pgsql-admin
On Tuesday, April 28, 2020, Rui DeSousa <rui@crazybean.net> wrote:
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.

pgsql-admin by date:

Previous
From: Tim Cross
Date:
Subject: Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Next
From: Rui DeSousa
Date:
Subject: Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)