Re: Can we go beyond the standard to make Postgres radically better?

I mean: it’s hard to write, hard to read. It’s hard to generate. But that’s just the starting point.

One of the worst things about it that I don’t see much discussed is that it imposes assumptions about the storage model that aren’t part of the relational model. Like heavyweight, hard to change tables with transactional guarantees and such. Don’t get me wrong, those things are great to have available, but I don’t need them all the time.

The whole NoSQL movement has been such a tragedy. Having diagnosed a problem with SQL databases, they threw out the relational model and very often reimplemented a form of SQL when they should have done the opposite. There is no reason you can’t have a relational database with an on-demand schema, with eventual consistency, with all those fun things that various NoSQL databases provide. Those storage models have their place, but the SQL standard says you can’t use them.

But the biggest issue is the verbose, terrible, very bad query language. In the web development community where I spend my time, it is almost holy writ to treat the database as a dumb data bucket, and do everything in the application layer (even things like validations, even when that is a provably incorrect approach). Why? I think it’s because they’re used to working in a pleasant language like Ruby or Python, and they want to do everything there. And who can blame them?

But this is bad. Proper relational design can take over much (most!) of the design of a typical business app, with significant efficiency gains the result. But no *community* is going to choose that when most of the members of the community don’t want to learn SQL and who can blame them?

Another issue: everyone thinks “relational” is the same thing as “SQL”. If we could get folks to break that association, then relations should be a standard feature of high-level programming languages, just as arrays and hashes are.

Heck, give me a functional programming language with a good relational model, and I can implement OOP in that relational language without breaking a sweat.

Software *should* be designed around a logical/relational layer with minimal occasional forays into Turing completeness where necessary. But no-one is even thinking about software like that because relational is SQL and SQL is awful.