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

On Feb 10, 2022, at 17:06 , Mladen Gogala <gogala.mladen@gmail.com> wrote:

But SQL is a terrible, no good, very bad language.

I cannot accept such a religious persecution of SQL without a detailed explanation.

I feel like anyone who is defending SQL here isn’t aware of how much better the alternatives are, and how bad SQL really is.

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

OK. If there are better alternatives, I am sure you will be able to sell them to the world. Establish a company and have a go at it.

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.

Storage model and implementation are not part of SQL for good reason. Database vendors have different implementations. MySQL and Postgres are different. MySQL storage engines differ among themselves. Both of them are different from SQL Server which is in turn different from Oracle and DB2. Storage model determines the implementation. When there is only a single relational database vendor left in the market, then they can burn their storage implementation into the language standard. Until then, the more, the merrier.

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?

As a database architect who has successfully bridged two very different database systems, I can tell you that the application programmers put the business logic into the application because they frequently don't know what the options are. They know Java or Python and that's what they do, period. That has nothing to do with SQL.

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.

There is such thing as "free market". If you offer them a better alternative, people will come. You may be the next Larry Ellison. And then again, you may be not. There is only one way to tell, and that's not proselytizing on the Postgres mailing list.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com