Even then you should use text, just with a CHECK constraint. That's easier to change later than a varchar column.

Yes. The most complicated migrations I've ever done have involved increasing the length of varchar(n) columns, because every dependent view needed to be dropped and recreated (and all of their dependents, and so on, recursively) within the migration transaction, in the right sequence.

If I had just used the text datatype in the first place (along with a check constraint), these migrations would have been so much simpler.

You had views dependent on views? Object oriented database schemes sound problematic.

Nothing to do with object orientation. We just use a lot of views, both to abstract away common complex queries, and to allow external systems to interact with the data in a controlled way.

That makes sense actually. But stored procedures could do that too?

Yes. I tend to treat procedural code as a last resort, because pure declarative SQL is so much easier to troubleshoot.

I guess I use stored procedures differently. I rely on SQL queries not for loops if I can help it. Sometimes it can’t be avoided if you’re doing updates in chunks for example.

I think is super weird that databases can have developer-hostile designs like this and still be considered "world class". If a web all framework had pitfalls like these, people would rageblog them into oblivion. I'm not trying to single out postgres because I have the impression that the same holds for all databases over some age.

I mean, most of this article reads as a list of features postgres never should've had. If PHP can deprecate magic quotes, then why can't postgres do something similar? Why do the "string data type" docs contain anything other than the "text" type, outside a section titled "deprecated, do not use"? Why isn't there a strict mode that warns me when I'm trying to use Bad Ideas From The Nineties?

Every single technology that lives long enough has legacy features like these and antipatterns. When compared to other software of similar age, this is remarkable little cruft.

Every tool that's powerful enough needs to have caveats. I agree it's a PITA, but this is orders of magnitude better than say, bash, C++, Linux, or PHP.

Strict mode sounds like an awesome idea. From time to time people release database schema linting scripts, those might help?

They can't deprecate varchar and some other ill advised field types because they are required to comply with the SQL standard.

The text thing, though, has never been a secret. Learning about it is sort of a coming of age ritual for postgres developers.

Postgres' warts are nowhere as unpredictable and problematic as magic quotes. Apart from those things, most RDBMs are incredibly stable and ironed-out workhouses and are nowhere as controversial than PHP is.

Even better, make a domain type encapsulating the constraint.

I sometimes use a limit (constraint or varchar(n)) to enforce an upper bound when the domain doesn't really demand one, but you'd rather get an error that a longer string in your database. Say, 100 characters for a login name or 1000 characters for a real person's name.

Even if somebody actually shows up with a longer name, you know that your application will have other problems in that case (e.g. the UI explodes or something), but you prevent the occasional bug or other problem from writing megabytes into the name field, and causing follow-up problems.