Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
| От | David G. Johnston |
|---|---|
| Тема | Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length) |
| Дата | |
| Msg-id | CAKFQuwaQ3Wxbqgs6es6Rh8NO9Ugn8VEUNMPjoErCX17a2wY51w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length) (Rui DeSousa <rui@crazybean.net>) |
| Ответы |
Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
|
| Список | 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 по дате отправления: