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

From Rui DeSousa
Subject Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Date
Msg-id D9F0D7D1-9D46-4B9B-8B62-EE139159F62E@crazybean.net
Whole thread Raw
In response to Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)  (raf <raf@raf.org>)
Responses Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
List pgsql-admin


On Apr 28, 2020, at 10:29 PM, raf <raf@raf.org> wrote:

Rui DeSousa wrote:

On Apr 28, 2020, at 7:43 PM, raf <raf@raf.org> wrote:

I just use "text" for everything. It's less typing. :-)

Ugh, I see it as sign that the designers of the schema didn’t fully
think about the actual requirements or care about them and it usually
shows.

You are mistaken. I care a lot. That's why I
future-proof designs whenever possible by
not imposing arbitrarily chosen limits that
appear to suit current requirements.

In other words, I know I'm not smart enough
to predict the future so I don't let that
fact ruin my software. :-)

cheers,
raf


Arbitrarily? What’s a cusip, vin, ssn?  Why would you put a btree index on a text field? Because it’s not.

What you’re advocating is a NoSQL design — defer your schema design.  Letting the application code littered in multiple places elsewhere define what a cusip, etc. is. 



pgsql-admin by date:

Previous
From: raf
Date:
Subject: Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)
Next
From: "David G. Johnston"
Date:
Subject: Re: PostgreSQL CHARACTER VARYING vs CHARACTER VARYING (Length)