> - Postgres' version of upsert allowed any command to be run without checking the permissions. So the vaunted "software engineering" behind Postgres is not tha

> - Postgres' version of upsert allowed any command to be run without checking the permissions. So the vaunted "software engineering" behind Postgres is not that solid. That never was the case (see evidence in initial commit [1]). Are you talking about CVE-2017-15099? Obviously annoying that we had that bug, but thats very far from what you claim. Since you write "I'd appreciate if you're itching to write a hasty response that you actually check your facts first." you actually follow up your own advice? > - Postgres' COPY FROM and COPY TO have been used to compromise the database by copying ssh keys to the server, amongst other things. If, and only if, the user is a superuser. It's possible to do the same in just about any other client/server rdbms. > Some constructive advice to the Postgres developers is to take a week and add grant commands to limit COPY FROM and COPY TO You mean, like it has been the case for ~19 years? https://www.postgresql.org/docs/7.1/sql-copy.html https://www.postgresql.org/docs/7.1/sql-copy.html "COPY naming a file is only allowed to database superusers, since it allows writing on any file that the backend has privileges to write on.". > - Currently Postgres is subject to around a dozen metasploit vulnerabilities that any script-kiddy can execute. That does not actually seem to be the case (what a surprise). And the modules that do exist are one for a (serious!) vulnerability from 2013, and others that aren't vulnerabilities because they require superuser rights. [1] https://github.com/postgres/postgres/commit/168d5805e4c08bed7b95d351bf097cff7c07dd65#diff-552e7a346d85054654b4be84c6ac5211 https://github.com/postgres/postgres/commit/168d5805e4c08bed...