PostgreSQL Adds GSSAPI Encryption Support

[phoronix]

Phoronix: PostgreSQL Adds GSSAPI Encryption Support

Adding to the list of features to get excited about with PostgreSQL 12 is support for GSSAPI encryption...

http://www.phoronix.com/scan.php?page=news_item&px=PostgreSQL-GSSAPI-Encryption

[uid313]

A bad thing with PostgreSQL is that it pollutes the file system with confusing names that is not clearly related to PostgreSQL such as "createdb", and "createuser".
Most binaries are prefixed with the pg_ prefix though, but not unfortunately not all.

Microsoft SQL Server supports data masking, but PostgreSQL only supports it via extensions or scripts.

[andrei_me]

For wine we have that guy that posts video of "This Wine version"

For postgres we have uid complaining about JSON standard and now binary name and location.

I wonder where GhostOfFunks would be~~

[tildearrow]

For wine we have that guy that posts video of "This Wine version"

For postgres we have uid complaining about JSON standard and now binary name and location.

I wonder where GhostOfFunks would be~~

For systemd we have Weasel and hreindl turning the thread into a 50-page disaster.

For every thread we have debianxfce coming out of nowhere and spreading his Debian XFCE 1000Hz GStreamer wicd propaganda over and over again.

(Also, please remember that for Firefox we also have uid complaining about dialog, datetime-local and system-ui)

[Vistaus]

(Also, please remember that for Firefox we also have uid complaining about dialog, datetime-local and system-ui)

And he also asks (mostly the same) questions in every PHP, GNOME Shell and Wayland thread.

[ehansin]

A bad thing with PostgreSQL is that it pollutes the file system with confusing names that is not clearly related to PostgreSQL such as "createdb", and "createuser".
Most binaries are prefixed with the pg_ prefix though, but not unfortunately not all.

I thought I might catch you on this thread The article is paywall covered until it gets freely released to non-subscribers, but I saw this on LWN the other day and thought of you:

"A Linux user's $PATH likely contains well over a thousand different commands that were installed by various packages. It's not immediately obvious which package is responsible for a command with a generic name, like createuser. There are ways to figure it out, of course, but perhaps it would make sense for packages like PostgreSQL, which is responsible for createuser, to give their commands names that are less generic—and more easily disambiguated—such as pg_createuser. But renaming commands down the road has "backward compatibility problems" written all over it, as a recent discussion on the pgsql-hackers mailing list shows."

https://lwn.net/Articles/784508/

[Bsdisbetter]

I thought I might catch you on this thread The article is paywall covered until it gets freely released to non-subscribers, but I saw this on LWN the other day and thought of you:

"A Linux user's $PATH likely contains well over a thousand different commands that were installed by various packages. It's not immediately obvious which package is responsible for a command with a generic name, like createuser. There are ways to figure it out, of course, but perhaps it would make sense for packages like PostgreSQL, which is responsible for createuser, to give their commands names that are less generic—and more easily disambiguated—such as pg_createuser. But renaming commands down the road has "backward compatibility problems" written all over it, as a recent discussion on the pgsql-hackers mailing list shows."

https://lwn.net/Articles/784508/

I've never seen it as a problem because standard users never have it in their path and nor should they (and it's useless to them anyway). Much ado about nothing. It seems like an objection based on ignorance.

[Bsdisbetter]

A bad thing with PostgreSQL is that it pollutes the file system with confusing names that is not clearly related to PostgreSQL such as "createdb", and "createuser".
Most binaries are prefixed with the pg_ prefix though, but not unfortunately not all.

Microsoft SQL Server supports data masking, but PostgreSQL only supports it via extensions or scripts.

Yes, they're deal breakers. I'd keep using ms sql if i was you.

[uid313]

I've never seen it as a problem because standard users never have it in their path and nor should they (and it's useless to them anyway). Much ado about nothing. It seems like an objection based on ignorance.

It is in the standard path on Ubuntu.

Yes, they're deal breakers. I'd keep using ms sql if i was you.

Microsoft SQL Server is a really good database.
But all databases are pretty good these days.

Microsoft SQL Server used to be bad back in the days of SQL Server 2005 but SQL Server 2012 and 2016 are nice.
MySQL used to bad back in the days too, but since version 8.0 it is nice.

PostgreSQL is really nice too. Like really nice. Great compatibility with Oracle, very much features, and good standards compliance.

https://en.wikipedia.org/wiki/SQL_compliance

It's just too bad there are couple things that are less good with it, such as the file system pollution and confusing, inconsistently, unpredictable named executable where some but not all share the pg_ prefix.
And and that everything is scattered around dozens of executables, instead of like in Git where everything is under one wrapper.

[Bsdisbetter]

It is in the standard path on Ubuntu.

Change the path, or don't use Ubuntu. I don't see this as some insurmountable issue, surely?
A normal user (non database administrator) doesn't need this stuff in their path and a database administrator should know the commands if it's in their path.
If you're running a system with users, it's on you to make sure paths are relevant. Likewise, role based access control is a treat for this.

I am in an organization that uses postgres extensively. If we want data masking we've got stuff like provided by cybertec. Either way in the bad old days this was all accomplished by scripts and programs or just being lazy and letting developers use a copy of the production databases...