News for hackers. Stuff that matters.
Re:Common mistakes in PostgreSQL by fabian2k on Friday May 03, 2019 @08:51AM (#19817926)
Even then you should use text, just with a CHECK constraint. That's easier to change later than a varchar column.
Re:Common mistakes in PostgreSQL by radiowave on Friday May 03, 2019 @09:28AM (#19818184)
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.

Re:Common mistakes in PostgreSQL by gigatexal on Friday May 03, 2019 @01:24PM (#19820314)
You had views dependent on views? Object oriented database schemes sound problematic.
Re:Common mistakes in PostgreSQL by radiowave on Friday May 03, 2019 @03:18PM (#19821399)
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.
Re:Common mistakes in PostgreSQL by gigatexal on Saturday May 04, 2019 @02:12AM (#19824758)
That makes sense actually. But stored procedures could do that too?
Re:Common mistakes in PostgreSQL by radiowave on Saturday May 04, 2019 @05:22AM (#19825368)
Yes. I tend to treat procedural code as a last resort, because pure declarative SQL is so much easier to troubleshoot.
Re:Common mistakes in PostgreSQL by gigatexal on Saturday May 04, 2019 @01:57PM (#19828043)
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.
Re:Common mistakes in PostgreSQL by skrebbel on Friday May 03, 2019 @12:18PM (#19819707)
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?

Re:Common mistakes in PostgreSQL by Daishiman on Friday May 03, 2019 @01:05PM (#19820160)
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.

Re:Common mistakes in PostgreSQL by jrumbut on Friday May 03, 2019 @04:17PM (#19821879)
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.

Re:Common mistakes in PostgreSQL by samus on Sunday May 05, 2019 @02:16AM (#19831444)
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.
Re:Common mistakes in PostgreSQL by snuxoll on Friday May 03, 2019 @01:58PM (#19820675)
Even better, make a domain type encapsulating the constraint.