Re: PostgreSQL pollutes the file system
От | Tomas Vondra |
---|---|
Тема | Re: PostgreSQL pollutes the file system |
Дата | |
Msg-id | 20190327142657.GC17983@development обсуждение исходный текст |
Ответ на | Re: PostgreSQL pollutes the file system (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: PostgreSQL pollutes the file system
Re: PostgreSQL pollutes the file system |
Список | pgsql-hackers |
On Wed, Mar 27, 2019 at 03:07:24PM +0100, Andreas Karlsson wrote: >On 3/27/19 2:51 PM, Tomas Vondra wrote: >>I think the consensus in this thread (and the previous ancient ones) is >>that it's not worth it. It's one thing to introduce new commands with the >>pg_ prefix, and it's a completely different thing to rename existing ones. >>That has inherent costs, and as Tom pointed out the burden would fall on >>people using PostgreSQL (and that's rather undesirable). >> >>I personally don't see why having commands without pg_ prefix would be >>an issue. Especially when placed in a separate directory, which eliminates >>the possibility of conflict with other commands. > >I buy that it may not be worth breaking tens of thousands of scripts >to fix this, but I disagree about it not being an issue. Most Linux >distributions add PostgreSQL's executables in to a directory which is >in the default $PATH (/usr/bin in the case of Debian). And even if it >would be installed into a separate directory there would still be a >conflict as soon as that directory is added to $PATH. > That is true, of course. But are there actual examples of such conflicts in practice? I mean, are there tools/packages that provide commands with a conflicting name? I'm not aware of any, and as was pointed before, we'd have ~20 years of history on any new ones. >And I think that it is also relatively easy to confuse adduser and >createuser when reading a script. Nothing about the name createuser >indicates that it will create a role in an SQL database. > Sure, and I've confused those tools too in the past. But that's not something you'll hit in a script, at least not if you test it before running it on production system. And if you're running untested scripts, this is likely the least of your problems ... cheers -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: