Re: Can I get some PostgreSQL developer feedback on these five general issues I have with PostgreSQL and its ecosystem?

tutiluren(at)tutanota(dot)com schrieb am 25.09.2020 um 06:41:
> All lowercase is good
>
> That's your personal opinion -- not some kind of fact, and it
> definitely goes against everything that I believe.
You have to accept that every programming environment has its own best practices
(in terms of coding style AND naming conventions). The recommendation to use all
lower-case unquoted names is not Gavin's personal opinion, it's the opinion
of the Postgres community.

In Postgres and many other relational databases - with SQL Server and MySQL being the (only?) exception -
using non-quoted identifiers is the recommended way. In Oracle, DB2 or Firebird this leads to all uppercase
names, in Postgres to all lowercase names.

If you don't follow the recommended best practices, you can't really blame those that do (e.g. the PostGIS project),
for your problems.

> The fact that there are a lot of sloppy, US-centric people who refuse
> to use correctly named identifiers and cannot understand how there
> can be anything besides a-z in an alphabet, doesn't change reality
> and doesn't make a bug "right".

I am not in the USA (and far from being US-centric as well) and I have been working
with relational databases for over thirty years. I never had problems using unquoted
ASCII names (using snake_case) for my database objects.

Would it be nice if I could use special characters like öäü in the names of tables and columns (without the hassle of quoting them)?
Yes, absolutely.

Does not using them, limit me in any way doing what I want to do?
No, it doesn't.

> Always the same thing. The slightest criticism, no matter how
> warranted, always results in: "Fine. Go somewhere else. Use something
> else."
> Never: "Oh, right. Sorry, but we always used lowercase ourselves and
> therefore didn't consider this. In retrospect, it's an embarrassing
> mistake! We'll fix it in the next release. Thanks for pointing that
> out."

Changing this behaviour has been discussed on this list multiple times.

The problem is, that currently no one sees a way to change this without
breaking all (or most) existing code that relies on it (at least not with
the resources the project hast).

It's my understanding (as a user, not a developer) that the impact on the code base would be huge, and
the community doesn't indeed really see a benefit in doing so.

It has especially been discussed to implement a behaviour that complies
with the SQL standard which *requires* to fold non-quoted names to uppercase!

Would you be more happy with a standard compliant behaviour?
I guess not.

So, this is indeed one of the things that you either have to accept, or move on.

*Every* piece of software has some quirks (or bugs as you see it) which are annoying
and can't or won't be changed. If the number of quirks (or bugs) exceeds the benefit
you get from the software, then you should indeed start looking for something different.

But claiming that the people on this list are not open to criticism is simply wrong and
doesn't do them justice.
You might want to search the internet on the reaction to Uber's change from Postgres
to MySQL - many of the criticism from their side have resulted in changes to
Postgres. And there are many other examples (e.g. Windows port, replication, vacuum problems).

You are unlucky to be offended by the best practices when it comes to naming
database objects. I think having a "case preserving, case insensitive"
option in Postgres would be nice indeed, but it's not a _functional_ problem,
it's just an aesthetic one. Sticking to the recommended best practices
doesn't limit you in any way in exploiting all features of the software.

> The answer, of course, is that you have zero interest in helping but
> 100% interest in making smug insults,
The only person who is insulting other people is you.

But you apparently have zero interest in accepting that different environments, need different approaches.
And what works in "System A" does not work the same in "System B".

Thomas