Re: PostgreSQL pollutes the file system
Andreas Karlsson wrote: > The Debian packagers already use pg_createcluster for their script which > wraps initdb, and while pg_initdb is a bit misleading (it creates a > cluster rather than a database) it is not that bad. But that renaming wouldn't achieve anything in relation to the stated goal, since initdb is not in the $PATH in Debian/Ubuntu systems. It's part of the version-specific binaries located in /usr/lib/postgresql/$VERSION/bin, which are not meant to be called directly, but by the pg_*cluster* scripts that you mention, or pg_wrapper. Moreover, aside from package-specific issues, initdb can already be invoked through "pg_ctl initdb" since 2010 and version 9.0, as mentioned in: https://www.postgresql.org/docs/9.0/app-initdb.html This evolution was the result of discussions pretty much like the present thread. 9 years later, who bothers to use or recommend the new form? AFAICS nobody cares. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
Re: PostgreSQL pollutes the file system
On Sat, Apr 13, 2019 at 3:36 PM Tomas Vondra wrote: > On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote: > >So there is no regression potential. > > > > I fail to understand how you came to this conclusion? Andreas pointed > out Debian already uses pg_createcluster, so there clearly is potential > for conflict and a regression. But there is no "createcluster" in PostgreSQL so that is not a problem. I don't know if there is any other third-party programs that carry the pg_ prefix though. > >When and who can send the patch to rename the programs to carry the > >pg_ prefixes, and create symlinks from the old names? > > > > Well, presumably that would be you, sometime in the future? It would be better if someone with more experienced than me did it. > TBH I don't quite understand what are we trying to achieve in this > thread. It started with the presumption that PostgreSQL "pollutes" the > filesystem with scripts/binaries - which may or may not be true, but for > the sake of the argument let's assume that it is. How does keeping the > original stuff and adding symblinks improve the situation? It would ease in discoverability and make the user space more coherent and predictable which would make it easier to use. It would also allow to move the symlinks into an optional package or remove them in the future.
Re: PostgreSQL pollutes the file system
Please don't top post. It makes it unnecessarily difficult to follow the discussion. See https://wiki.postgresql.org/wiki/Mailing_Lists On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote: So there is no regression potential. I fail to understand how you came to this conclusion? Andreas pointed out Debian already uses pg_createcluster, so there clearly is potential for conflict and a regression. When and who can send the patch to rename the programs to carry the pg_ prefixes, and create symlinks from the old names? Well, presumably that would be you, sometime in the future? TBH I don't quite understand what are we trying to achieve in this thread. It started with the presumption that PostgreSQL "pollutes" the filesystem with scripts/binaries - which may or may not be true, but for the sake of the argument let's assume that it is. How does keeping the original stuff and adding symblinks improve the situation? On Fri, Apr 12, 2019 at 5:19 PM Andreas Karlsson wrote: On 4/12/19 5:14 PM, Chris Travers wrote: > 1. naming things is surprisingly hard. How sure are we that we can do > this right? Can we come up with a correct name for initdb? Maybe > pg_createcluster? The Debian packagers already use pg_createcluster for their script which wraps initdb, and while pg_initdb is a bit misleading (it creates a cluster rather than a database) it is not that bad. Andreas regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
So there is no regression potential. When and who can send the patch to rename the programs to carry the pg_ prefixes, and create symlinks from the old names? On Fri, Apr 12, 2019 at 5:19 PM Andreas Karlsson wrote: > > On 4/12/19 5:14 PM, Chris Travers wrote: > > 1. naming things is surprisingly hard. How sure are we that we can do > > this right? Can we come up with a correct name for initdb? Maybe > > pg_createcluster? > > The Debian packagers already use pg_createcluster for their script which > wraps initdb, and while pg_initdb is a bit misleading (it creates a > cluster rather than a database) it is not that bad. > > Andreas
Re: PostgreSQL pollutes the file system
Could I please ask a couple of questions? Why does the first answer to everything seem to be "we need to destroy something to make it better for others"? Why does createdb need to be removed? Why do we use the "newbie that can't understand whether or not createdb is for PostgreSQL or MySQL or " and then ignore the fact that this would be the one person least able to handle a breakage of a 5 year old internal script that simply does it's job for them each day? What if someone has a nice little script that is really well written and fails on warnings because the company policy is that "warnings are to be respected"? How does that person properly do their job if they need to break open that script one morning because we've dropped a "warning bomb" on them without any option but to fix the entire script in one shot with no option to continue otherwise? What if there is a semi-strict QA policy at said company and they are placed in a bind due to the volume and nature of the changes required here because of steps taken that are impossible to reasonably work around (possibly even outside of the script itself)? So I would like to offer the beginning of a "framework" of steps that could accomplish the desired task with the bare minimum of breakage and with simple steps that can be offered to help people affected by these changes. 1) Any new name is a symlink to the old name. We do not break existing tooling for any non-obvious reason. Any notion of symlinking the old names and then discussing "packagers could add a PostgreSQL-Legacy-Symlinks package" is not ok. We cannot have users breaking because of a missing package and then have them running around with their head cut off trying to figure out where that package is for their particular system. We make across the board changes that are easily explainable. 2) We can certainly add a warning to the old names that warn of future removal. However we need to offer a simple option to remove these warnings in a future friendly fashion. Remember the person that is not ok running around deep inside a 1000 line script. 3) Long term (or even fairly short term) we move the old names back to a more appropriate location - lets say /opt//pgsql/bin - if someone ignored the warnings then they are broken - there is nothing that can be done with that - but we've now accomplished the stated goal - hide names like "createdb" from standard paths. However how do we deal with the VERY bad side of #2/#3? That's what i feel has been missing here. So lets walk through something If someone has a script that breaks on warnings - or they are generally not someone that is comfortable making many changes to a script - we need a single line option for them. WARNING - createdb is no longer the preferred method - please either change to pg_createdb OR add the following line near the top of your script/environment source pg_legacy_environment (Wording is not my strong suit - bear with me please) What is pg_legacy_environment? Well it's a provided file that starts it's life as simple as this export PG_LEGACY_ENVIRONMENT=1 And the warnings that check for usage of the old command names check for PG_LEGACY_ENVIRONMENT and understand that if that variable exists - the user has chosen to make the minimal change to their script and should be respected. We will fix their environment for them as needed to allow them to continue using old names. That solves #2 and allows for someone to very quickly remove warnings without any major changes. A single line change is as simple as one can imagine or do. If someone cannot accomplish this change - what possibly can we do for them? When #3 hits and the old names are removed from the path - pg_legacy_environment could change to something along these lines export PATH=$PATH:/opt/pgsql/bin And now we have a removal of the old names, that does not break anyone that has followed the warning until this point - and allows for a simple, one line fix, to anyone that walks in the door and screams FIRE because they ignored the warning and now have a problem. I feel the above respects the people that are supposed to be the people we have empathy for - they are also steps that can be done even fairly quickly because the fix is handled via modification to the script environment as opposed to the core workings of a script itself. In fact - one could add the pg_legacy_environment line to their shell environment and not even modify a single script at all. John
Re: PostgreSQL pollutes the file system
On 4/12/19 5:14 PM, Chris Travers wrote: 1. naming things is surprisingly hard. How sure are we that we can do this right? Can we come up with a correct name for initdb? Maybe pg_createcluster? The Debian packagers already use pg_createcluster for their script which wraps initdb, and while pg_initdb is a bit misleading (it creates a cluster rather than a database) it is not that bad. Andreas
Re: PostgreSQL pollutes the file system
On Fri, Apr 12, 2019 at 3:20 PM Alvaro Herrera wrote: > On 2019-Apr-12, Daniel Gustafsson wrote: > > > There are many good reasons for the changes proposed in this thread, but > I'm > > not sure if discoverability is one. Relying on autocompleting a > filename to > > figure out existing tooling for database maintenance and DBA type > operations > > seems like a fragile usecase. > > > > If commandline discoverability is of importance, providing a summary of > the > > tools in "man postgresql" seems like a better option. > > The first comment in the LWN article: > "It's broken and obviously a bad idea but we've been doing it for so long > we > shouldn't attempt to fix it" > > IMO the future is longer than the past, and has more users, so let's do > it right instead of perpetuating the mistakes. > I agree we should look at fixing these. However I have two concerns. 1. naming things is surprisingly hard. How sure are we that we can do this right? Can we come up with a correct name for initdb? Maybe pg_createcluster? 2. How long would our deprecation cycle be? 5 years? 10 years? Given that people may need to support multiple versions I would propose no warnings until both formats are supported, then warnings for 2 years, then drop the old ones. > > > ... unless you think PostgreSQL is going to become irrelevant before > 2050. > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > -- Best Regards, Chris Travers Head of Database Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
Re: PostgreSQL pollutes the file system
I think of discoverability as as how easy it is to discover and rediscover things. Like rediscover commands you forgot the name of. Like "what was the command to create a database?", just type pg_ and press tab and see whats there. The LWN article is now unlocked to all readers, not just paying subscribers. It have many comments which might bring value to this discussion. https://lwn.net/Articles/784508/ On Fri, Apr 12, 2019 at 3:37 PM Daniel Gustafsson wrote: > > On Friday, April 12, 2019 3:20 PM, Alvaro Herrera > wrote: > > > On 2019-Apr-12, Daniel Gustafsson wrote: > > > > > There are many good reasons for the changes proposed in this thread, but > > > I'm > > > not sure if discoverability is one. Relying on autocompleting a filename > > > to > > > figure out existing tooling for database maintenance and DBA type > > > operations > > > seems like a fragile usecase. > > > If commandline discoverability is of importance, providing a summary of > > > the > > > tools in "man postgresql" seems like a better option. > > > > The first comment in the LWN article: > > "It's broken and obviously a bad idea but we've been doing it for so long we > > shouldn't attempt to fix it" > > > > IMO the future is longer than the past, and has more users, so let's do > > it right instead of perpetuating the mistakes. > > > > ... unless you think PostgreSQL is going to become irrelevant before > > 2050. > > Not at all, and as I said there are many good reasons for doing this. I just > don't think "discoverability" is the driver, since I consider that a different > thing from ease of use and avoid confusion with system tools etc (my reading > of > that word is "finding something new", not "how did I spell that tool again"). > > cheers ./daniel
Re: PostgreSQL pollutes the file system
On Friday, April 12, 2019 3:20 PM, Alvaro Herrera wrote: > On 2019-Apr-12, Daniel Gustafsson wrote: > > > There are many good reasons for the changes proposed in this thread, but I'm > > not sure if discoverability is one. Relying on autocompleting a filename to > > figure out existing tooling for database maintenance and DBA type operations > > seems like a fragile usecase. > > If commandline discoverability is of importance, providing a summary of the > > tools in "man postgresql" seems like a better option. > > The first comment in the LWN article: > "It's broken and obviously a bad idea but we've been doing it for so long we > shouldn't attempt to fix it" > > IMO the future is longer than the past, and has more users, so let's do > it right instead of perpetuating the mistakes. > > ... unless you think PostgreSQL is going to become irrelevant before > 2050. Not at all, and as I said there are many good reasons for doing this. I just don't think "discoverability" is the driver, since I consider that a different thing from ease of use and avoid confusion with system tools etc (my reading of that word is "finding something new", not "how did I spell that tool again"). cheers ./daniel
Re: PostgreSQL pollutes the file system
On 2019-Apr-12, Daniel Gustafsson wrote: > There are many good reasons for the changes proposed in this thread, but I'm > not sure if discoverability is one. Relying on autocompleting a filename to > figure out existing tooling for database maintenance and DBA type operations > seems like a fragile usecase. > > If commandline discoverability is of importance, providing a summary of the > tools in "man postgresql" seems like a better option. The first comment in the LWN article: "It's broken and obviously a bad idea but we've been doing it for so long we shouldn't attempt to fix it" IMO the future is longer than the past, and has more users, so let's do it right instead of perpetuating the mistakes. ... unless you think PostgreSQL is going to become irrelevant before 2050. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
I would disagree. Discoverability is important, and having a user space that is intuitive and predictable. With the discoverability exposed by pg_ then you immediately find out what is available. One shouldn't have to delve down into manuals and books. Then forget what that darn command was next time its needed, just to have to return to the documentation again. Preferably a wrapper around the tools could provide a summary for all the tools, just like git --help. On Fri, Apr 12, 2019 at 2:56 PM Daniel Gustafsson wrote: > > On Friday, April 12, 2019 2:25 PM, Fred .Flintstone > wrote: > > > It would make the old commands more easily discoverable. Just type pg_ > > and press the tab key for auto-completion. > > There are many good reasons for the changes proposed in this thread, but I'm > not sure if discoverability is one. Relying on autocompleting a filename to > figure out existing tooling for database maintenance and DBA type operations > seems like a fragile usecase. > > If commandline discoverability is of importance, providing a summary of the > tools in "man postgresql" seems like a better option. > > cheers ./daniel
Re: PostgreSQL pollutes the file system
On Friday, April 12, 2019 2:25 PM, Fred .Flintstone wrote: > It would make the old commands more easily discoverable. Just type pg_ > and press the tab key for auto-completion. There are many good reasons for the changes proposed in this thread, but I'm not sure if discoverability is one. Relying on autocompleting a filename to figure out existing tooling for database maintenance and DBA type operations seems like a fragile usecase. If commandline discoverability is of importance, providing a summary of the tools in "man postgresql" seems like a better option. cheers ./daniel
Re: PostgreSQL pollutes the file system
It would make the old commands more easily discoverable. Just type pg_ and press the tab key for auto-completion. On Wed, Apr 10, 2019 at 9:46 PM Peter Eisentraut wrote: > > On 2019-04-10 15:01, Tatsuo Ishii wrote: > >> On 2019-03-29 20:32, Joe Conway wrote: > >>> pg_util > >> > >> How is that better than just renaming to pg_$oldname? > > > > As I already said in up thread: > > > >> This way, we would be free from the command name conflict problem > > Well, whatever we do -- if anything -- we would certainly need to keep > the old names around for a while somehow. So this doesn't really make > that issue go away. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
>>> On 2019-03-29 20:32, Joe Conway wrote: pg_util >>> >>> How is that better than just renaming to pg_$oldname? >> >> As I already said in up thread: >> >>> This way, we would be free from the command name conflict problem > > Well, whatever we do -- if anything -- we would certainly need to keep > the old names around for a while somehow. So this doesn't really make > that issue go away. Another complain was, it's hard to remember the tool names for novice users. I think this way would solve the problem. I agree that command name conflicting problem will not be solved by the idea. However I do not believe there's name conflicting problem in the first place. So I am happy to keep the old names as they are. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: PostgreSQL pollutes the file system
Em sex, 29 de mar de 2019 às 13:25, Tom Lane escreveu: > > Maybe if we want to merge these things into one executable, > it should be a new one. "pg_util createrole bob" ? > +1 as I proposed in https://www.postgresql.org/message-id/bdd1adb1-c26d-ad1f-2f15-cc52056065d4%40timbira.com.br -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Re: PostgreSQL pollutes the file system
I just want to be on record that I don't think there is a problem here that needs to be solved. The choice to put Postgres-related binaries in /usr/bin or wherever is a distribution/packaging decision. As has been pointed out, if I download, build, and install Postgres, the binaries by default go in /usr/local/pgsql/bin. It is a long-standing Unix tradition to have short-named commands from many sources in /usr/bin and /bin, not to mention other files, often with short names, in various directories all over the system. For example, on one of the Ubuntu machines at my work, take a look at all the 2-character commands in those directories, and how many different packages they come from, in the list at the bottom of this message. At this point I think Postgres absolutely owns the name "psql" as a Unix binary and I would oppose any suggestion that this should be renamed. Just my own effort to teach my fingers to type something different would probably outweigh any benefit from renaming. Having said this, if people are enthusiastic and can actually agree, there are a few changes that might make sense: - move clusterdb, createdb, etc. (*db, but not initdb because that is a server, not client, program) into pg_db_util [subcommand] (or some such) - move createuser, dropuser into pg_role_util [subcommand] (or some such) - pgbench -> pg_bench (why no '_' anyway?) - ecpg -> pg_ec (usually invoked by makefiles anyway, I'm guessing) But I consider this worth doing only if people consider that it's an improvement for reasons other than just getting stuff out of /bin or /usr/bin. List of 2-character commands and their source packages on one of our systems (the "no path found" ones are mostly symlinks into the Ubuntu "alternatives" system): 16:52 ijmorlan@ubuntu1604-102$ dpkg -S /usr/bin/?? /bin/?? | sort dpkg-query: no path found matching pattern /usr/bin/cc dpkg-query: no path found matching pattern /usr/bin/ex dpkg-query: no path found matching pattern /usr/bin/fp dpkg-query: no path found matching pattern /usr/bin/js dpkg-query: no path found matching pattern /usr/bin/pc dpkg-query: no path found matching pattern /usr/bin/rn dpkg-query: no path found matching pattern /usr/bin/rt dpkg-query: no path found matching pattern /usr/bin/vi dpkg-query: no path found matching pattern /bin/mt dpkg-query: no path found matching pattern /bin/nc acct: /usr/bin/ac apache2-utils: /usr/bin/ab aspectj: /usr/bin/aj at: /usr/bin/at bc: /usr/bin/bc bf: /usr/bin/bf binutils: /usr/bin/ar binutils: /usr/bin/as binutils: /usr/bin/ld binutils: /usr/bin/nm bsdmainutils: /usr/bin/hd bsdmainutils: /usr/bin/ul byobu: /usr/bin/NF coreutils: /bin/cp coreutils: /bin/dd coreutils: /bin/df coreutils: /bin/ln coreutils: /bin/ls coreutils: /bin/mv coreutils: /bin/rm coreutils: /usr/bin/du coreutils: /usr/bin/id coreutils: /usr/bin/nl coreutils: /usr/bin/od coreutils: /usr/bin/pr coreutils: /usr/bin/tr coreutils: /usr/bin/wc cups-client: /usr/bin/lp dash: /bin/sh dc: /usr/bin/dc debhelper: /usr/bin/dh diversion by dash from: /bin/sh diversion by dash to: /bin/sh.distrib ed: /bin/ed ghostscript: /usr/bin/gs graphviz: /usr/bin/gc gv: /usr/bin/gv i3-wm: /usr/bin/i3 ii: /usr/bin/ii iproute2: /bin/ip iproute2: /bin/ss ispell: /usr/bin/sq login: /bin/su login: /usr/bin/sg m4: /usr/bin/m4 mc: /usr/bin/mc mercurial: /usr/bin/hg mono-devel: /usr/bin/al mono-devel: /usr/bin/lc mono-devel: /usr/bin/sn mtools: /usr/bin/lz mtools: /usr/bin/uz p7zip-full: /usr/bin/7z procps: /bin/ps rcs: /usr/bin/ci rcs: /usr/bin/co rs: /usr/bin/rs ruby: /usr/bin/ri sc: /usr/bin/sc speech-tools: /usr/bin/dp tex4ht: /usr/bin/ht texlive-binaries: /usr/bin/mf util-linux: /usr/bin/pg xz-utils: /usr/bin/xz
Re: PostgreSQL pollutes the file system
On 2019-04-10 15:01, Tatsuo Ishii wrote: >> On 2019-03-29 20:32, Joe Conway wrote: >>> pg_util >> >> How is that better than just renaming to pg_$oldname? > > As I already said in up thread: > >> This way, we would be free from the command name conflict problem Well, whatever we do -- if anything -- we would certainly need to keep the old names around for a while somehow. So this doesn't really make that issue go away. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 2019-04-10 15:15, Fred .Flintstone wrote: > The warnings would only be printed if the programs were executed with > the old file names. > This in order to inform people relying on the old names that they are > deprecated and they should move to the new names with the pg_ prefix. Yeah, that would be annoying. Let's not do that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Re: Fred .Flintstone 2019-04-10 > Does anyone oppose the proposal? I don't think part #3 has been discussed, and I'd oppose printing these warnings. Christoph
Re: PostgreSQL pollutes the file system
Does anyone oppose the proposal? How can we determine consensus? Is there any voting process? Is there any developer who is more versed than me with C than me who can write this patch? On Wed, Apr 10, 2019 at 2:52 PM Christoph Berg wrote: > > Re: Fred .Flintstone 2019-04-10 > > > It seems we do have a clear path forward on how to accomplish this and > > implement this change. > > > > 1. Rename executables to carry the pg_ prefix. > > 2. Create symlinks from the old names to the new names. > > 3. Modify the executables to read argv[0] and print a warning if the > > executable is called from the old name (symlink). > > > > This seems technically feasible and easy. > > > > How can we proceed? > > You can send a patch. > > But I don't think there has been a "clear" agreement that this is a > good idea. > > Christoph
Re: PostgreSQL pollutes the file system
> On 2019-03-29 20:32, Joe Conway wrote: >> pg_util > > How is that better than just renaming to pg_$oldname? As I already said in up thread: > This way, we would be free from the command name conflict problem > and plus, we could do: > > pgsql --help > > which will prints subscommand names when a user is not sure what is > the sub command name. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: PostgreSQL pollutes the file system
Re: Fred .Flintstone 2019-04-10 > It seems we do have a clear path forward on how to accomplish this and > implement this change. > > 1. Rename executables to carry the pg_ prefix. > 2. Create symlinks from the old names to the new names. > 3. Modify the executables to read argv[0] and print a warning if the > executable is called from the old name (symlink). > > This seems technically feasible and easy. > > How can we proceed? You can send a patch. But I don't think there has been a "clear" agreement that this is a good idea. Christoph
Re: PostgreSQL pollutes the file system
It seems we do have a clear path forward on how to accomplish this and implement this change. 1. Rename executables to carry the pg_ prefix. 2. Create symlinks from the old names to the new names. 3. Modify the executables to read argv[0] and print a warning if the executable is called from the old name (symlink). This seems technically feasible and easy. How can we proceed? On Tue, Apr 2, 2019 at 11:24 PM Fred .Flintstone wrote: > > It looks like this thread is featured on LWN under the article: > Program names and "pollution". > https://lwn.net/ > https://lwn.net/Articles/784508/ (Subscription required) > > On Sat, Mar 30, 2019 at 12:27 PM Peter Eisentraut > wrote: > > > > On 2019-03-29 20:32, Joe Conway wrote: > > > pg_util > > > > How is that better than just renaming to pg_$oldname? > > > > -- > > Peter Eisentraut http://www.2ndQuadrant.com/ > > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
It looks like this thread is featured on LWN under the article: Program names and "pollution". https://lwn.net/ https://lwn.net/Articles/784508/ (Subscription required) On Sat, Mar 30, 2019 at 12:27 PM Peter Eisentraut wrote: > > On 2019-03-29 20:32, Joe Conway wrote: > > pg_util > > How is that better than just renaming to pg_$oldname? > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 2019-03-29 20:32, Joe Conway wrote: > pg_util How is that better than just renaming to pg_$oldname? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 2019-03-29 16:41, Tom Lane wrote: > Or perhaps better, allow pg_ctl to grow new > subcommands for those tasks? pg_ctl is a tool to control the server; the commands being complained about are client-side things. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
I think the proposal you put forward is great, and would love to see it go ahead and get implemented. On Fri, Mar 29, 2019 at 5:35 PM Alvaro Herrera wrote: > > On 2019-Mar-29, Tom Lane wrote: > > > Christoph Berg writes: > > > What might possibly make sense is to add options to psql to > > > facilitate common tasks: > > > > > psql --createdb foo > > > psql --createuser bar --superuser > > > psql --reindex foo > > > > That's a thought. Or perhaps better, allow pg_ctl to grow new > > subcommands for those tasks? > > +1, as I proposed in 2016: > https://www.postgresql.org/message-id/20160826202911.GA320593@alvherre.pgsql > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 3/29/19 11:41 AM, Tom Lane wrote: > Christoph Berg writes: >> What might possibly make sense is to add options to psql to >> facilitate common tasks: >> psql --createdb foo >> psql --createuser bar --superuser >> psql --reindex foo > That's a thought. Or perhaps better, allow pg_ctl to grow new > subcommands for those tasks? > > I think that's a better direction. psql is already pretty cumbersome. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Re: Joe Conway 2019-03-29 > >> echo "\password :\"role\"" | psql -v role='my role' > > > > It is on-topic because the reason we can't just tell people to replace > > createuser $foo > > with > > psql -c "create user $foo" > > is because $foo might need escaping. > > > > IMHO if we find an way to do that which is acceptable for sh scripts, > > the createuser/... commands could go. > > I think these commands *were* once (at least some of them) shell scripts > and we went to executable C in order to make them work on Windows, IIRC. I meant the interface to these programs. It needs to be something people can use in sh scripts without wtf'ing. The :\"weirdness\" | cited above is IMHO not acceptable. Christoph
Re: PostgreSQL pollutes the file system
On 3/29/19 3:43 PM, Christoph Berg wrote: > Re: Joe Conway 2019-03-29 <48e5efaf-7ea2-ed70-a803-949bbfec8...@joeconway.com> >> echo "\password :\"role\"" | psql -v role='my role' >> Enter new password: >> Enter it again: >> >> That said, this is kind of off the topic of this thread. > > It is on-topic because the reason we can't just tell people to replace > createuser $foo > with > psql -c "create user $foo" > is because $foo might need escaping. > > IMHO if we find an way to do that which is acceptable for sh scripts, > the createuser/... commands could go. I think these commands *were* once (at least some of them) shell scripts and we went to executable C in order to make them work on Windows, IIRC. >> I like Tom's last suggestion of: >> >> pg_util >> >> Of course that does not lend itself to symlinking for backward >> compatibility, does it? If there is a way I am not familiar with it. > > We could symlink createuser -> pg_util. It is pretty common for > commands to act differently based on the name the were invoked as. Yeah, I forgot about that. Does that also go for Windows? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Re: PostgreSQL pollutes the file system
Re: Joe Conway 2019-03-29 <48e5efaf-7ea2-ed70-a803-949bbfec8...@joeconway.com> > echo "\password :\"role\"" | psql -v role='my role' > Enter new password: > Enter it again: > > That said, this is kind of off the topic of this thread. It is on-topic because the reason we can't just tell people to replace createuser $foo with psql -c "create user $foo" is because $foo might need escaping. IMHO if we find an way to do that which is acceptable for sh scripts, the createuser/... commands could go. > I like Tom's last suggestion of: > > pg_util > > Of course that does not lend itself to symlinking for backward > compatibility, does it? If there is a way I am not familiar with it. We could symlink createuser -> pg_util. It is pretty common for commands to act differently based on the name the were invoked as. > I guess the alternative would be an alias, but can packages install an > alias? Or something else I am not thinking about? Aliases won't work for non-interactive shell scripts. Christoph
Re: PostgreSQL pollutes the file system
On 3/29/19 3:32 PM, Joe Conway wrote: > pg_util > > Of course that does not lend itself to symlinking for backward > compatibility, does it? If there is a way I am not familiar with it. On Unix-like systems, you can have pg_util look at argv[0] to see if it was called createuser or what not. Not sure how translatable that is to other systems. Regards, -Chap
Re: PostgreSQL pollutes the file system
On 3/29/19 3:01 PM, Pavel Stehule wrote: > But psql has safe escaping via :"xxx" notation. So some like > > psql -c 'create role :"role"' -v role='my role' ... > > But what I know the psql variables are not evaluated for -c query You can do this: echo "create role :\"role\"" | psql -v role='my role' CREATE ROLE echo "\password :\"role\"" | psql -v role='my role' Enter new password: Enter it again: That said, this is kind of off the topic of this thread. I like Tom's last suggestion of: pg_util Of course that does not lend itself to symlinking for backward compatibility, does it? If there is a way I am not familiar with it. I guess the alternative would be an alias, but can packages install an alias? Or something else I am not thinking about? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Re: PostgreSQL pollutes the file system
pá 29. 3. 2019 v 19:50 odesílatel Christoph Berg napsal: > Re: Tom Lane 2019-03-29 <19517.1553876...@sss.pgh.pa.us> > > >> Or perhaps better, allow pg_ctl to grow new subcommands for those > > >> tasks? > > > > > We'd need to be careful to somehow delineate commands that need access > > > to the data directory / run locally on the server from the ones that > > > just needs a client connection. > > > > Hmm, that's a good point: to put it in terms that make sense to a > > packager, it'd no longer be clear whether pg_ctl belongs in the > > server package or the client package. > > True, and putting end-user commands like "create database" into the > same admin tool like "stop", "promote", and "kill" feels both wrong > and dangerous to me. It would also cause people to wonder why "pg_ctl > -h remotehost stop" doesn't work. > > > I'm still not thrilled with wedging in these things as options > > to psql though: its command line semantics are overly complicated > > already, when you consider things like multiple -c and -f options. > > I mean, somebody might think it's a feature to be able to do > > > > psql --createuser alice --createuser bob -c 'some command' -f > somefile > > > > but I don't. > > Ack. (Otoh, just processing all arguments after another might be > well-defined, and not too hard?) > > > Maybe if we want to merge these things into one executable, > > it should be a new one. "pg_util createrole bob" ? > > "pg" is unfortunately already taken :( > > Fwiw, let's please keep supporting "createuser". Creating login roles > is more common than non-login ones, and having to type "createrole > --login bob" is cumbersome and will cause endless support requests by > confused users. > > Other idea: If we don't want to reinvent a new tool, how about > supporting prepared statements in psql? > > psql -c 'create user %i' --args 'bob w. space' > Prepared statements cannot be DDL commands. But psql has safe escaping via :"xxx" notation. So some like psql -c 'create role :"role"' -v role='my role' ... But what I know the psql variables are not evaluated for -c query Pavel > > Christoph > > >
Re: PostgreSQL pollutes the file system
Re: Tom Lane 2019-03-29 <19517.1553876...@sss.pgh.pa.us> > >> Or perhaps better, allow pg_ctl to grow new subcommands for those > >> tasks? > > > We'd need to be careful to somehow delineate commands that need access > > to the data directory / run locally on the server from the ones that > > just needs a client connection. > > Hmm, that's a good point: to put it in terms that make sense to a > packager, it'd no longer be clear whether pg_ctl belongs in the > server package or the client package. True, and putting end-user commands like "create database" into the same admin tool like "stop", "promote", and "kill" feels both wrong and dangerous to me. It would also cause people to wonder why "pg_ctl -h remotehost stop" doesn't work. > I'm still not thrilled with wedging in these things as options > to psql though: its command line semantics are overly complicated > already, when you consider things like multiple -c and -f options. > I mean, somebody might think it's a feature to be able to do > > psql --createuser alice --createuser bob -c 'some command' -f somefile > > but I don't. Ack. (Otoh, just processing all arguments after another might be well-defined, and not too hard?) > Maybe if we want to merge these things into one executable, > it should be a new one. "pg_util createrole bob" ? "pg" is unfortunately already taken :( Fwiw, let's please keep supporting "createuser". Creating login roles is more common than non-login ones, and having to type "createrole --login bob" is cumbersome and will cause endless support requests by confused users. Other idea: If we don't want to reinvent a new tool, how about supporting prepared statements in psql? psql -c 'create user %i' --args 'bob w. space' Christoph
Re: PostgreSQL pollutes the file system
On 2019-Mar-29, Tom Lane wrote: > Christoph Berg writes: > > What might possibly make sense is to add options to psql to > > facilitate common tasks: > > > psql --createdb foo > > psql --createuser bar --superuser > > psql --reindex foo > > That's a thought. Or perhaps better, allow pg_ctl to grow new > subcommands for those tasks? +1, as I proposed in 2016: https://www.postgresql.org/message-id/20160826202911.GA320593@alvherre.pgsql -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Andres Freund writes: > On 2019-03-29 11:41:26 -0400, Tom Lane wrote: >> Or perhaps better, allow pg_ctl to grow new subcommands for those >> tasks? > We'd need to be careful to somehow delineate commands that need access > to the data directory / run locally on the server from the ones that > just needs a client connection. Hmm, that's a good point: to put it in terms that make sense to a packager, it'd no longer be clear whether pg_ctl belongs in the server package or the client package. I'm still not thrilled with wedging in these things as options to psql though: its command line semantics are overly complicated already, when you consider things like multiple -c and -f options. I mean, somebody might think it's a feature to be able to do psql --createuser alice --createuser bob -c 'some command' -f somefile but I don't. Maybe if we want to merge these things into one executable, it should be a new one. "pg_util createrole bob" ? regards, tom lane
Re: PostgreSQL pollutes the file system
Hi, On 2019-03-29 11:41:26 -0400, Tom Lane wrote: > Or perhaps better, allow pg_ctl to grow new subcommands for those > tasks? We'd need to be careful to somehow delineate commands that need access to the data directory / run locally on the server from the ones that just needs a client connection. Greetings, Andres Freund
Re: PostgreSQL pollutes the file system
On 3/29/19 11:44 AM, Daniel Gustafsson wrote: > On Friday, March 29, 2019 4:41 PM, Tom Lane wrote: > >> Christoph Berg m...@debian.org writes: >> >> > What might possibly make sense is to add options to psql to >> > facilitate common tasks: >> >> > psql --createdb foo >> > psql --createuser bar --superuser >> > psql --reindex foo >> >> That's a thought. Or perhaps better, allow pg_ctl to grow new >> subcommands for those tasks? > > +1 on using pg_ctl rather than psql, should we go down this path. Agreed -- another +1 here Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Re: PostgreSQL pollutes the file system
On Friday, March 29, 2019 4:41 PM, Tom Lane wrote: > Christoph Berg m...@debian.org writes: > > > What might possibly make sense is to add options to psql to > > facilitate common tasks: > > > psql --createdb foo > > psql --createuser bar --superuser > > psql --reindex foo > > That's a thought. Or perhaps better, allow pg_ctl to grow new > subcommands for those tasks? +1 on using pg_ctl rather than psql, should we go down this path. cheers ./daniel
Re: PostgreSQL pollutes the file system
Christoph Berg writes: > What might possibly make sense is to add options to psql to > facilitate common tasks: > psql --createdb foo > psql --createuser bar --superuser > psql --reindex foo That's a thought. Or perhaps better, allow pg_ctl to grow new subcommands for those tasks? regards, tom lane
Re: PostgreSQL pollutes the file system
Re: Tatsuo Ishii 2019-03-29 <20190329.100407.1159785913847835944.t-is...@sraoss.co.jp> > If we were to invent new command names, what about doing similar to > git? I mean something like: > > pgsql createdb That is pretty close to "psql" and it will be utterly confusing for new users. And everyone will have a hard time when talking about the tools, imagine someone saying "please run psql appdbname" or "please run pgsql createdb". The difference is just too small. What might possibly make sense is to add options to psql to facilitate common tasks: psql --createdb foo psql --createuser bar --superuser psql --reindex foo Christoph
Re: PostgreSQL pollutes the file system
I think that would be amazing! It would be great! On Fri, Mar 29, 2019 at 4:01 AM Tatsuo Ishii wrote: > > > Andreas Karlsson writes: > >> On 3/27/19 3:26 PM, Tomas Vondra wrote: > >>> 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. > > > >> That is a fair argument. Since we squatted those names back in the > >> mid-90s I think the risk of collision is low. > > > > Right. I think there is a fair argument to be made for user confusion > > (not actual conflict) with respect to createuser and dropuser. The > > argument for renaming any of the other tools is much weaker, IMO. > > If we were to invent new command names, what about doing similar to > git? I mean something like: > > pgsql createdb > > Here, "pgsql" is new command name and "createdb" is a sub command name > to create a database. > > This way, we would be free from the command name conflict problem and > plus, we could do: > > pgsql --help > > which will prints subscommand names when a user is not sure what is > the sub command name. > > Best regards, > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > English: http://www.sraoss.co.jp/index_en.php > Japanese:http://www.sraoss.co.jp
Re: PostgreSQL pollutes the file system
> Andreas Karlsson writes: >> On 3/27/19 3:26 PM, Tomas Vondra wrote: >>> 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. > >> That is a fair argument. Since we squatted those names back in the >> mid-90s I think the risk of collision is low. > > Right. I think there is a fair argument to be made for user confusion > (not actual conflict) with respect to createuser and dropuser. The > argument for renaming any of the other tools is much weaker, IMO. If we were to invent new command names, what about doing similar to git? I mean something like: pgsql createdb Here, "pgsql" is new command name and "createdb" is a sub command name to create a database. This way, we would be free from the command name conflict problem and plus, we could do: pgsql --help which will prints subscommand names when a user is not sure what is the sub command name. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: PostgreSQL pollutes the file system
So what we could do is: * Rename executables to be prefixed with pg_. Symlink old names to renamed executables. This while remaining 100% backwards compatibility, not breaking anything legacy. * Print warnings when the executables are executed using the symlink. * Have the option to have the symlinks in a different optional package. * At later time in the future be able to chose to remove the symlinks. On Thu, Mar 28, 2019 at 2:52 PM Tom Lane wrote: > > Alvaro Herrera writes: > > There are provisions in the manpage system to have some pages be > > symlinks to other pages. We don't currently use that anywhere, > > Actually we do, eg WITH is a link to SELECT. > > regards, tom lane
Re: PostgreSQL pollutes the file system
Alvaro Herrera writes: > There are provisions in the manpage system to have some pages be > symlinks to other pages. We don't currently use that anywhere, Actually we do, eg WITH is a link to SELECT. regards, tom lane
Re: PostgreSQL pollutes the file system
On 2019-Mar-28, Abel Abraham Camarillo Ojeda wrote: > On Thursday, March 28, 2019, Fred .Flintstone wrote: > > > There would be no need to remove anything if we just renamed the > > executable and created symlinks for them. > > Will there still be man pages for both commands? > > man pg_createuser > man createuser There are provisions in the manpage system to have some pages be symlinks to other pages. We don't currently use that anywhere, but I see no reason why we couldn't just do that. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On Thursday, March 28, 2019, Fred .Flintstone wrote: > There would be no need to remove anything if we just renamed the > executable and created symlinks for them. Will there still be man pages for both commands? man pg_createuser man createuser ? > > On Wed, Mar 27, 2019 at 10:20 PM Peter Eisentraut > wrote: > > > > On 2019-03-27 18:09, Tom Lane wrote: > > > My recollection of the discussion is that people argued that > "postmaster" > > > might be taken to have something to do with an e-mail server, and > > > therefore we needed to stop using that name. The lack of either > follow-on > > > complaints or follow-on action doesn't make me too well disposed to > > > what is essentially that same argument over again. > > > > The reason there was that the distinction was mostly useless and the > > different command-line option parsing was confusing. The name itself > > was confusing but not in conflict with anything. > > > > However, we do know that we are very bad at actually getting rid of > > deprecated things. > > > > How about we compromise in this thread and remove postmaster and leave > > everything else as is. ;-) > > > > -- > > Peter Eisentraut http://www.2ndQuadrant.com/ > > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > >
Re: PostgreSQL pollutes the file system
There would be no need to remove anything if we just renamed the executable and created symlinks for them. On Wed, Mar 27, 2019 at 10:20 PM Peter Eisentraut wrote: > > On 2019-03-27 18:09, Tom Lane wrote: > > My recollection of the discussion is that people argued that "postmaster" > > might be taken to have something to do with an e-mail server, and > > therefore we needed to stop using that name. The lack of either follow-on > > complaints or follow-on action doesn't make me too well disposed to > > what is essentially that same argument over again. > > The reason there was that the distinction was mostly useless and the > different command-line option parsing was confusing. The name itself > was confusing but not in conflict with anything. > > However, we do know that we are very bad at actually getting rid of > deprecated things. > > How about we compromise in this thread and remove postmaster and leave > everything else as is. ;-) > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 2019-03-27 18:09, Tom Lane wrote: > My recollection of the discussion is that people argued that "postmaster" > might be taken to have something to do with an e-mail server, and > therefore we needed to stop using that name. The lack of either follow-on > complaints or follow-on action doesn't make me too well disposed to > what is essentially that same argument over again. The reason there was that the distinction was mostly useless and the different command-line option parsing was confusing. The name itself was confusing but not in conflict with anything. However, we do know that we are very bad at actually getting rid of deprecated things. How about we compromise in this thread and remove postmaster and leave everything else as is. ;-) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 28/03/2019 03:41, Tom Lane wrote: Andreas Karlsson writes: On 3/27/19 3:26 PM, Tomas Vondra wrote: 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. That is a fair argument. Since we squatted those names back in the mid-90s I think the risk of collision is low. Right. I think there is a fair argument to be made for user confusion (not actual conflict) with respect to createuser and dropuser. The argument for renaming any of the other tools is much weaker, IMO. regards, tom lane I think the consistency of having all PostgreSQL commands start with 'pg_' would make them both easier to find and to learn. Although I think we should keep the psql command name, in addition to the pg_sql variant - the latter needed for consistency. Cheers, Gavin
Re: PostgreSQL pollutes the file system
On 28/03/2019 03:07, 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. 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. Andreas Existing users would feel some pain, but continued use of commands 'creatuser' rather than pg_createuser (better still pg_createrole, as suggested elsewhere) create confusion and display unintended arrogance. There is a suggestion to use aliases, and I think that is a good interim step, to introduce the 'pg_' variants. Possible with an option at install time to force only 'pg_' variants (with the possible exception of psql). The only command, that I think warrants a permanent alias is psql, which I think is not ambiguous, but having a pg_sql for consistency would be good. Cheers, Gavin
Re: PostgreSQL pollutes the file system
On 2019-Mar-27, Tom Lane wrote: > Alvaro Herrera writes: > > I suppose that if you're a Postgres developer, you naturally expect that > > "createdb" creates a Postgres DB. What if you use multiple database > > systems, and then only occasionally have to do DBA tasks? I find this > > POV that createdb doesn't need renaming a bit self-centered. > > Nobody is defending the existing names as being something we'd pick > if we were picking them today. The question is whether changing them > is worth the pain. (And, one more time, may I point out that most > of the pain will be borne by people not on this mailing list, hence > unable to vote here.) I don't think there is any reasonable argument > that said pain will be justified for any of them except maybe createuser > and dropuser. The implicit argument here is that existing users are a larger population than future users. I, for one, don't believe that. I think taking no action is a disservice to future users. Also, that modifying the code will be utterly painful and that less administrative code will be written in the future than has already been written. We *could* run a poll on twitter/slack/website to get a feeling on a wider population. That would still reach mostly existing Postgres users, but at least it would be much more diverse than this group. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Symlinks would be great, because then the symlinks could be packaged as an optional package. such as; - postgresql-11 - postgresql-client-11 - postgresql-client-symlinks-11 - postgresql-client-common - postgresql-common Then one might chose to not install the symlinks package or uninstall it. And it would ease discoverability, predictability, intuitiveness, and ease-of-use so much by just being able to type pg_ to discover all the PostgreSQL-related commands. On Wed, Mar 27, 2019 at 6:26 PM Petr Jelinek wrote: > > On 27/03/2019 15:26, Tomas Vondra wrote: > > 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. > > It's only partially true, for example on my systems: > > Debian/Ubuntu: > $ readlink -f /usr/bin/createuser > /usr/share/postgresql-common/pg_wrapper > > Centos (PGDG package): > readlink -f /usr/bin/createdb > /usr/pgsql-11/bin/createdb > > This also means that the idea about symlinks is something packages > already do. > > -- > Petr Jelinek http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services
Re: PostgreSQL pollutes the file system
On 27/03/2019 15:26, Tomas Vondra wrote: > 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. It's only partially true, for example on my systems: Debian/Ubuntu: $ readlink -f /usr/bin/createuser /usr/share/postgresql-common/pg_wrapper Centos (PGDG package): readlink -f /usr/bin/createdb /usr/pgsql-11/bin/createdb This also means that the idea about symlinks is something packages already do. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: PostgreSQL pollutes the file system
Alvaro Herrera writes: > I suppose that if you're a Postgres developer, you naturally expect that > "createdb" creates a Postgres DB. What if you use multiple database > systems, and then only occasionally have to do DBA tasks? I find this > POV that createdb doesn't need renaming a bit self-centered. Nobody is defending the existing names as being something we'd pick if we were picking them today. The question is whether changing them is worth the pain. (And, one more time, may I point out that most of the pain will be borne by people not on this mailing list, hence unable to vote here.) I don't think there is any reasonable argument that said pain will be justified for any of them except maybe createuser and dropuser. >> "postmaster" symlink, though it's been deprecated for at least a >> dozen years.) > I don't think that change was because of executable namespace pollution > or user confusion. (Commit 5266f221a2e1, can't find the discussion > though.) My recollection of the discussion is that people argued that "postmaster" might be taken to have something to do with an e-mail server, and therefore we needed to stop using that name. The lack of either follow-on complaints or follow-on action doesn't make me too well disposed to what is essentially that same argument over again. regards, tom lane
Re: PostgreSQL pollutes the file system
On Wed, 2019-03-27 at 15:07 +0100, Andreas Karlsson wrote: > [EXTERNAL SOURCE] > > > > 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. > > 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. > > Andreas > theres nothing about createuser or adduser( useradd on my system, adduser doesn't exist on mine ) that indicates that either would/should create a user in the system either. That's what man and -h/--help are for. If you don't know what an executable does, don't invoke it until you do. That's a basic premise for any executable. reid
Re: PostgreSQL pollutes the file system
On 2019-Mar-27, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Mar-27, 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 thought the consensus was to rename them, and install symlinks to the > > old names. > > The question is what's the endgame. We haven't actually fixed the > complained-of confusion problem unless we eventually remove createuser > and dropuser under those names. Well, partly we have, because there mere act of having a symlink documents the command via the symlink target. Somebody proposed to rename createuser not to pg_createuser, though, but rather to pg_createrole; ditto dropuser. That seems to make sense. I additionally proposed (nobody replied to this part) that we could have the command print a WARNING if the argv[0] is shown to be the old name. Not necessarily in pg12; maybe we can have them print such a warning in pg13, and then remove the old names three years from now, or something like that. I suppose that if you're a Postgres developer, you naturally expect that "createdb" creates a Postgres DB. What if you use multiple database systems, and then only occasionally have to do DBA tasks? I find this POV that createdb doesn't need renaming a bit self-centered. > Are we prepared to force script breakage of that sort, even over a > multi-year deprecation cycle? Why not? > (As a comparison point, I note that we still haven't removed the > "postmaster" symlink, though it's been deprecated for at least a > dozen years.) I don't think that change was because of executable namespace pollution or user confusion. (Commit 5266f221a2e1, can't find the discussion though.) -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Andreas Karlsson writes: > On 3/27/19 3:26 PM, Tomas Vondra wrote: >> 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. > That is a fair argument. Since we squatted those names back in the > mid-90s I think the risk of collision is low. Right. I think there is a fair argument to be made for user confusion (not actual conflict) with respect to createuser and dropuser. The argument for renaming any of the other tools is much weaker, IMO. regards, tom lane
Re: PostgreSQL pollutes the file system
On 3/27/19 3:26 PM, Tomas Vondra wrote: 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. That is a fair argument. Since we squatted those names back in the mid-90s I think the risk of collision is low. Andreas
Re: PostgreSQL pollutes the file system
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
Re: PostgreSQL pollutes the file system
Alvaro Herrera writes: > On 2019-Mar-27, 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 thought the consensus was to rename them, and install symlinks to the > old names. The question is what's the endgame. We haven't actually fixed the complained-of confusion problem unless we eventually remove createuser and dropuser under those names. Are we prepared to force script breakage of that sort, even over a multi-year deprecation cycle? (As a comparison point, I note that we still haven't removed the "postmaster" symlink, though it's been deprecated for at least a dozen years.) regards, tom lane
Re: PostgreSQL pollutes the file system
On Wed, Mar 27, 2019 at 11:00:18AM -0300, Alvaro Herrera wrote: On 2019-Mar-27, 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 thought the consensus was to rename them, and install symlinks to the old names. I know symlinks were mentioned/proposed, but I don't think there's a clear consensus to do that. I might have missed that part of the discussion. That being said, I'm not strongly opposed to doing that, although I still don't see the need to do that ... regard -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
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. 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. Andreas
Re: PostgreSQL pollutes the file system
Hello, at the very least my Ubuntu Cosmic has createdb, createuser and createlang in user's space, and I had at least two cases when people were trying to use createuser to create a new OS user. I would prefer them having pg_ prefix to have less confusion. On Wed, Mar 27, 2019 at 4:51 PM Tomas Vondra wrote: > On Wed, Mar 27, 2019 at 02:31:14PM +0100, Fred .Flintstone wrote: > >Many of these are gone in the modern PostgreSQL, a few remain. > >https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist > > > >/usr/lib/postgresql/11/bin/clusterdb > >/usr/lib/postgresql/11/bin/createdb > >/usr/lib/postgresql/11/bin/createuser > >/usr/lib/postgresql/11/bin/dropdb > >/usr/lib/postgresql/11/bin/dropuser > >/usr/lib/postgresql/11/bin/pg_basebackup > >/usr/lib/postgresql/11/bin/pg_dump > >/usr/lib/postgresql/11/bin/pg_dumpall > >/usr/lib/postgresql/11/bin/pg_isready > >/usr/lib/postgresql/11/bin/pg_receivewal > >/usr/lib/postgresql/11/bin/pg_recvlogical > >/usr/lib/postgresql/11/bin/pg_restore > >/usr/lib/postgresql/11/bin/psql > >/usr/lib/postgresql/11/bin/reindexdb > >/usr/lib/postgresql/11/bin/vacuumdb > > > >Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix? > > > > 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. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > > > -- Darafei Praliaskouski Support me: http://patreon.com/komzpa
Re: PostgreSQL pollutes the file system
It does not matter if they are in a different directory, because when I use tab-completion in the shell, then all commands show. I type "create" then "createdb" and "createuser" shows up. This is very confusing, and I don't know if this creates a Linux system user account or a PostgreSQL account. Without knowing better, I would be inclined to believe such a command would create a system account. It gets even more confusing when a user have multiple database servers installed such as MySQL and PostgreSQL or MongoDB and PostgreSQL. Then it is very confusing what "createdb" does. On Wed, Mar 27, 2019 at 2:51 PM Tomas Vondra wrote: > > On Wed, Mar 27, 2019 at 02:31:14PM +0100, Fred .Flintstone wrote: > >Many of these are gone in the modern PostgreSQL, a few remain. > >https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist > > > >/usr/lib/postgresql/11/bin/clusterdb > >/usr/lib/postgresql/11/bin/createdb > >/usr/lib/postgresql/11/bin/createuser > >/usr/lib/postgresql/11/bin/dropdb > >/usr/lib/postgresql/11/bin/dropuser > >/usr/lib/postgresql/11/bin/pg_basebackup > >/usr/lib/postgresql/11/bin/pg_dump > >/usr/lib/postgresql/11/bin/pg_dumpall > >/usr/lib/postgresql/11/bin/pg_isready > >/usr/lib/postgresql/11/bin/pg_receivewal > >/usr/lib/postgresql/11/bin/pg_recvlogical > >/usr/lib/postgresql/11/bin/pg_restore > >/usr/lib/postgresql/11/bin/psql > >/usr/lib/postgresql/11/bin/reindexdb > >/usr/lib/postgresql/11/bin/vacuumdb > > > >Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix? > > > > 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. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: PostgreSQL pollutes the file system
On 2019-Mar-27, 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 thought the consensus was to rename them, and install symlinks to the old names. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On Wed, Mar 27, 2019 at 02:31:14PM +0100, Fred .Flintstone wrote: Many of these are gone in the modern PostgreSQL, a few remain. https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist /usr/lib/postgresql/11/bin/clusterdb /usr/lib/postgresql/11/bin/createdb /usr/lib/postgresql/11/bin/createuser /usr/lib/postgresql/11/bin/dropdb /usr/lib/postgresql/11/bin/dropuser /usr/lib/postgresql/11/bin/pg_basebackup /usr/lib/postgresql/11/bin/pg_dump /usr/lib/postgresql/11/bin/pg_dumpall /usr/lib/postgresql/11/bin/pg_isready /usr/lib/postgresql/11/bin/pg_receivewal /usr/lib/postgresql/11/bin/pg_recvlogical /usr/lib/postgresql/11/bin/pg_restore /usr/lib/postgresql/11/bin/psql /usr/lib/postgresql/11/bin/reindexdb /usr/lib/postgresql/11/bin/vacuumdb Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix? 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. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Many of these are gone in the modern PostgreSQL, a few remain. https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist /usr/lib/postgresql/11/bin/clusterdb /usr/lib/postgresql/11/bin/createdb /usr/lib/postgresql/11/bin/createuser /usr/lib/postgresql/11/bin/dropdb /usr/lib/postgresql/11/bin/dropuser /usr/lib/postgresql/11/bin/pg_basebackup /usr/lib/postgresql/11/bin/pg_dump /usr/lib/postgresql/11/bin/pg_dumpall /usr/lib/postgresql/11/bin/pg_isready /usr/lib/postgresql/11/bin/pg_receivewal /usr/lib/postgresql/11/bin/pg_recvlogical /usr/lib/postgresql/11/bin/pg_restore /usr/lib/postgresql/11/bin/psql /usr/lib/postgresql/11/bin/reindexdb /usr/lib/postgresql/11/bin/vacuumdb Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix? On Fri, Mar 22, 2019 at 3:13 AM Mark Kirkwood wrote: > > On 22/03/19 3:05 PM, Tom Lane wrote: > > Michael Paquier writes: > >> I would be curious to hear the reason why such tool names have been > >> chosen from the start. The tools have been switched to C in 9e0ab71 > >> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from > >> 1999, and I cannot spot the thread from the time where this was > >> discussed. > > createuser, at least, dates back to Berkeley days: my copy of the > > PG v4r2 tarball contains a "src/bin/createuser/createuser.sh" file > > dated 1994-03-19. (The 1999 commit you mention just moved the > > functionality around; it was there before.) So I imagine the answer > > is that nobody at the time thought of fitting these scripts into a > > larger ecosystem. > > > FWIW the whole set is there in version 6.4.2: > > markir@vedavec:/download/postgres/src/postgresql-6.4.2/src/bin$ ls -l > total 72 > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 cleardbdir > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 createdb > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 createuser > drwxr-sr-x 2 markir adm 4096 Dec 31 1998 CVS > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 destroydb > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 destroyuser > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 initdb > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 initlocation > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 ipcclean > -rw-r--r-- 1 markir adm 795 Dec 19 1998 Makefile > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pgaccess > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_dump > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_encoding > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_id > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_passwd > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pgtclsh > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_version > drwxr-sr-x 3 markir adm 4096 Dec 31 1998 psql > > -- > > Mark > >
Re: PostgreSQL pollutes the file system
On 22/03/19 3:05 PM, Tom Lane wrote: > Michael Paquier writes: >> I would be curious to hear the reason why such tool names have been >> chosen from the start. The tools have been switched to C in 9e0ab71 >> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from >> 1999, and I cannot spot the thread from the time where this was >> discussed. > createuser, at least, dates back to Berkeley days: my copy of the > PG v4r2 tarball contains a "src/bin/createuser/createuser.sh" file > dated 1994-03-19. (The 1999 commit you mention just moved the > functionality around; it was there before.) So I imagine the answer > is that nobody at the time thought of fitting these scripts into a > larger ecosystem. FWIW the whole set is there in version 6.4.2: markir@vedavec:/download/postgres/src/postgresql-6.4.2/src/bin$ ls -l total 72 drwxr-sr-x 3 markir adm 4096 Dec 31 1998 cleardbdir drwxr-sr-x 3 markir adm 4096 Dec 31 1998 createdb drwxr-sr-x 3 markir adm 4096 Dec 31 1998 createuser drwxr-sr-x 2 markir adm 4096 Dec 31 1998 CVS drwxr-sr-x 3 markir adm 4096 Dec 31 1998 destroydb drwxr-sr-x 3 markir adm 4096 Dec 31 1998 destroyuser drwxr-sr-x 3 markir adm 4096 Dec 31 1998 initdb drwxr-sr-x 3 markir adm 4096 Dec 31 1998 initlocation drwxr-sr-x 3 markir adm 4096 Dec 31 1998 ipcclean -rw-r--r-- 1 markir adm 795 Dec 19 1998 Makefile drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pgaccess drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_dump drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_encoding drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_id drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_passwd drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pgtclsh drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_version drwxr-sr-x 3 markir adm 4096 Dec 31 1998 psql -- Mark
Re: PostgreSQL pollutes the file system
Michael Paquier writes: > I would be curious to hear the reason why such tool names have been > chosen from the start. The tools have been switched to C in 9e0ab71 > from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from > 1999, and I cannot spot the thread from the time where this was > discussed. createuser, at least, dates back to Berkeley days: my copy of the PG v4r2 tarball contains a "src/bin/createuser/createuser.sh" file dated 1994-03-19. (The 1999 commit you mention just moved the functionality around; it was there before.) So I imagine the answer is that nobody at the time thought of fitting these scripts into a larger ecosystem. regards, tom lane
Re: PostgreSQL pollutes the file system
On Thu, Mar 21, 2019 at 10:02:40AM -0400, Tom Lane wrote: > So there seems like a real risk that taking away createuser would > result in security holes, not just annoying-but-trivial script update > work. That puts me more in the camp of "if we're going to do anything, > rename it with a pg_ prefix" than "if we're going to do anything, > remove it". Removing it would be a bad idea as it is very easy to mess up with things in such cases. As you mentioned, renaming the tools now would create more pain than actually solving things, so that's a bad idea anyway. I would be curious to hear the reason why such tool names have been chosen from the start. The tools have been switched to C in 9e0ab71 from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from 1999, and I cannot spot the thread from the time where this was discussed. -- Michael signature.asc Description: PGP signature
Re: PostgreSQL pollutes the file system
Andreas Karlsson writes: > On 3/21/19 7:07 AM, Chris Travers wrote: >> 1. createuser/dropuser are things that I don't consider good ways of >> creating users anyway. > Those binaries are pretty convenient to use in scripts since they handle > SQL escaping for you, but probably not convenient enough that we would > have added createuser today. > Compare > createuser "$USER" > vs > echo 'CREATE ROLE :"user" LOGIN' | psql postgres -v "user=$USER" Hmm. That example is actually quite scary, because while nearly anybody who's ever done any shell scripting would get the first one right, the second one requires a fair deal of specialized knowledge and creativity. I fear that 99% of people would have coded it like echo "CREATE USER $USER" | psql or some variant on that, and now they have a SQL-injection hazard that they didn't have before. So there seems like a real risk that taking away createuser would result in security holes, not just annoying-but-trivial script update work. That puts me more in the camp of "if we're going to do anything, rename it with a pg_ prefix" than "if we're going to do anything, remove it". regards, tom lane
Re: PostgreSQL pollutes the file system
Then someone who don't want the symlinks could delete them. Or the symlinks could ship in an optional postgesql-legacy-symlinks package. On Wed, Mar 20, 2019 at 6:32 PM Alvaro Herrera wrote: > > On 2019-Mar-20, Fred .Flintstone wrote: > > > Even just creating symlinks would be a welcome change. > > So the real binary is pg_foo and foo is a symoblic link that points to > > pg_foo. > > Then at least I can type pg_ and use tab auto-completion to find > > everything related to PostgreSQL. > > There is merit to this argument; if the starting point is an unknown > file /usr/bin/foo, then having it be a symlink to /usr/bin/pg_foo makes > it clear which package it belongs to. We don't *have to* get rid of the > symlinks any time soon, but installing as symlinks now will allow Skynet > to get rid of them some decades from now. > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
The binaries: * clusterdb * createdb * createuser * dropdb * dropuser * reindexdb * vacuumdb On Wed, Mar 20, 2019 at 8:13 PM Jonathan S. Katz wrote: > > On 3/20/19 2:08 PM, Alvaro Herrera wrote: > > On 2019-Mar-20, Euler Taveira wrote: > > > >> Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: > >>> > >>> We managed to get rid of createlang and droplang in v10, and there > >>> hasn't been that much push-back about it. So maybe there could be > >>> a move to remove createuser/dropuser? Or at least rename them to > >>> pg_createuser and pg_dropuser. But I think this was discussed > >>> (again) during the v10 cycle, and we couldn't agree to do more than > >>> get rid of createlang/droplang. > > > > Previous discussion: > > https://postgr.es/m/CABUevExPrfPH5K5qM=zst7tvfyace+i5qja6bfwckkyrh8m...@mail.gmail.com > > > >> Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I > >> said in the other email). However, if we don't have sufficient votes, > >> let's at least consider a 'pg_' prefix. > > > > I vote to keep these rename these utilities to have a pg_ prefix and to > > simultaneously install symlinks for their current names, so that nothing > > breaks. > > This sounds like a reasonable plan, pending which binaries we feel to do > that with. > > Pardon this naive question as I have not used such systems in awhile, > but would this work on systems that do not support symlinks? > > Jonathan >
Re: PostgreSQL pollutes the file system
I would be fine with that. We can make an exception for psql. As long as we get rid of: * clusterdb * createdb * createuser * dropdb * dropuser * reindexdb * vacuumdb On Wed, Mar 20, 2019 at 7:11 PM Tom Lane wrote: > > "Fred .Flintstone" writes: > > Even just creating symlinks would be a welcome change. > > So the real binary is pg_foo and foo is a symoblic link that points to > > pg_foo. > > Then at least I can type pg_ and use tab auto-completion to find > > everything related to PostgreSQL. > > You'd miss psql. I think the odds of renaming psql are not > distinguishable from zero: whatever arguments you might want to make > about, say, renaming initdb perhaps not affecting too many scripts > are surely not going to fly for psql. So that line of argument > isn't too convincing. > > regards, tom lane
Re: PostgreSQL pollutes the file system
On 3/21/19 7:07 AM, Chris Travers wrote: 1. createuser/dropuser are things that I don't consider good ways of creating users anyway. I think we should just consider removing these binaries. The SQL queries are better, more functional, and can be rolled back as a part of a larger transaction. Those binaries are pretty convenient to use in scripts since they handle SQL escaping for you, but probably not convenient enough that we would have added createuser today. Compare createuser "$USER" vs echo 'CREATE ROLE :"user" LOGIN' | psql postgres -v "user=$USER" Andreas
Re: PostgreSQL pollutes the file system
On 2019-Mar-20, Tomas Vondra wrote: > So to me this seems like a fairly invasive change (potentially breaking > quite a few scripts/tools) just to address a minor inconvenience. I don't think anything would break, actually. What are you thinking would break? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On Thu, Mar 21, 2019 at 1:49 AM Michael Paquier wrote: > On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote: > >> Can someone describe a scenario where this (name of the binary not > >> clearly indicating it's related postgres) causes issues in practice? On > >> my system, there are ~1400 binaries in /usr/bin, and for the vast > >> majority of them it's rather unclear where do they come from. > > Naming conflict because our binary names are too generic? createdb > could for example be applied to any database, and not only Postgres. > (I have 1600 entries in /usr/bin on a Debian installation.) > I generally agree with Tom that there is sufficient precedence here that we don't need to worry about these conflicts per se. However I would add two points where we might want to think: 1. createuser/dropuser are things that I don't consider good ways of creating users anyway. I think we should just consider removing these binaries. The SQL queries are better, more functional, and can be rolled back as a part of a larger transaction. 2. initdb is not so much of a pressing issue but I think despite the longer string, pg_ctl -D mydatadir init [options] would be clearer from a new user perspective and pose less cognitive load. > > >> > >> But it's not really an issue, because we have tools to do that > >> > >> 1) man > >> > >> 2) -h/--help > >> > >> 3) rpm -qf $file (and similarly for other packagers) > >> > >> 4) set --prefix to install binaries so separate directory (which some > >> distros already do anyway) > >> > >> So to me this seems like a fairly invasive change (potentially breaking > >> quite a few scripts/tools) just to address a minor inconvenience. > > > > +1. > > Yes, +1. > -- > Michael > -- Best Regards, Chris Travers Head of Database Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
Re: PostgreSQL pollutes the file system
On 3/20/19 8:19 PM, Andres Freund wrote: On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: If we are evaluating this whole symlink / renaming thing, there could be arguments for a "pgsql" alias to psql (or vice versa), but I don't think "pg_sql" makes any sense and could be fairly confusing. I don't care much about createdb etc, but I'm *strongly* against renaming psql and/or adding symlinks. That's like 95% of all interactions people have with postgres binaries, making that more confusing would be an enterily unnecessary self own. +1 "psql" as a tool for connecting to PostgreSQL is so well established that renaming it would just confuse everyone. Andreas
Re: PostgreSQL pollutes the file system
At 2019-03-20 23:22:44 +0100, tomas.von...@2ndquadrant.com wrote: > > I don't really understand what issue are we trying to solve here. > > Can someone describe a scenario where this (name of the binary not > clearly indicating it's related postgres) causes issues in practice? > On my system, there are ~1400 binaries in /usr/bin, and for the vast > majority of them it's rather unclear where do they come from. It sounds like a problem especially when described with charged terms like "pollutes", but I agree with you and others that it just doesn't seem worth the effort to try to rename everything. -- Abhijit
Re: PostgreSQL pollutes the file system
Tomas Vondra writes: > On 3/21/19 1:49 AM, Michael Paquier wrote: >> On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote: >>> Can someone describe a scenario where this (name of the binary not >>> clearly indicating it's related postgres) causes issues in practice? >> Naming conflict because our binary names are too generic? > Maybe. Do we actually know about such cases? More to the point, we have now got twenty+ years seniority on any other package that might want those /usr/bin names. So a conflict is not *really* going to happen, or at least it's not going to be our problem if it does. The whole thing is unfortunate, without a doubt, but it's still unclear that renaming those programs will buy anything that's worth the conversion costs. I'd be happy to pay said costs if it were all falling to this project to do so ... but most of the pain will be borne by other people. regards, tom lane
Re: PostgreSQL pollutes the file system
On 3/21/19 1:49 AM, Michael Paquier wrote: > On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote: >>> Can someone describe a scenario where this (name of the binary not >>> clearly indicating it's related postgres) causes issues in practice? On >>> my system, there are ~1400 binaries in /usr/bin, and for the vast >>> majority of them it's rather unclear where do they come from. > > Naming conflict because our binary names are too generic? createdb > could for example be applied to any database, and not only Postgres. > (I have 1600 entries in /usr/bin on a Debian installation.) > Maybe. Do we actually know about such cases? Also, isn't setting --prefix a suitable solution? I mean, it's what we/packagers do to support installing multiple Pg versions (in which case it'll conflict no matter how we rename stuff) anyway. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote: >> Can someone describe a scenario where this (name of the binary not >> clearly indicating it's related postgres) causes issues in practice? On >> my system, there are ~1400 binaries in /usr/bin, and for the vast >> majority of them it's rather unclear where do they come from. Naming conflict because our binary names are too generic? createdb could for example be applied to any database, and not only Postgres. (I have 1600 entries in /usr/bin on a Debian installation.) >> >> But it's not really an issue, because we have tools to do that >> >> 1) man >> >> 2) -h/--help >> >> 3) rpm -qf $file (and similarly for other packagers) >> >> 4) set --prefix to install binaries so separate directory (which some >> distros already do anyway) >> >> So to me this seems like a fairly invasive change (potentially breaking >> quite a few scripts/tools) just to address a minor inconvenience. > > +1. Yes, +1. -- Michael signature.asc Description: PGP signature
Re: PostgreSQL pollutes the file system
> I don't really understand what issue are we trying to solve here. > > Can someone describe a scenario where this (name of the binary not > clearly indicating it's related postgres) causes issues in practice? On > my system, there are ~1400 binaries in /usr/bin, and for the vast > majority of them it's rather unclear where do they come from. > > But it's not really an issue, because we have tools to do that > > 1) man > > 2) -h/--help > > 3) rpm -qf $file (and similarly for other packagers) > > 4) set --prefix to install binaries so separate directory (which some > distros already do anyway) > > So to me this seems like a fairly invasive change (potentially breaking > quite a few scripts/tools) just to address a minor inconvenience. +1. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: PostgreSQL pollutes the file system
>> +1. As one of third party PostgreSQL tool developers, I am afraid >> changing names of PostgreSQL commands would give us lots of pain: for >> example checking PostgreSQL version to decide to use command "foo" not >> "pg_foo". >> > createdb, dropdb, createuser, dropuser, reindexdb are binaries that > confuse most newbies. Which tool is theses binaries from? The names > does not give a hint. How often those confusing name tools are used? > AFAICS a graphical tool or psql is used to create roles and databases. > psql -c "stmt" can replace createdb, dropdb, createuser and dropuser. > What about deprecate them (and remove after a support cycle)? At least psql, initdb, pg_config, pgbench and pg_ctl for now. But I don't want to say that renaming other commands would be fine for me because I would like to take a liberty to extend my tool for my users. BTW, a strange thing in the whole discussion is, installing those PostgreSQL commands in /usr/bin is done by packagers, not PostgreSQL core project itself. The default installation directory has been /usr/local/pgsql/bin in the source code of PostgreSQL since it was born, and I love the place. Forcing to install everything into /usr/bin is distributions' policy, not PostgreSQL core project's as far as I know. So I wonder why people don't ask the renaming request to packagers, rather than PostgreSQL core project itself. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: PostgreSQL pollutes the file system
On 3/20/19 7:08 PM, Alvaro Herrera wrote: > On 2019-Mar-20, Euler Taveira wrote: > >> Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: >>> >>> We managed to get rid of createlang and droplang in v10, and there >>> hasn't been that much push-back about it. So maybe there could be >>> a move to remove createuser/dropuser? Or at least rename them to >>> pg_createuser and pg_dropuser. But I think this was discussed >>> (again) during the v10 cycle, and we couldn't agree to do more than >>> get rid of createlang/droplang. > > Previous discussion: > https://postgr.es/m/CABUevExPrfPH5K5qM=zst7tvfyace+i5qja6bfwckkyrh8m...@mail.gmail.com > >> Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I >> said in the other email). However, if we don't have sufficient votes, >> let's at least consider a 'pg_' prefix. > > I vote to keep these rename these utilities to have a pg_ prefix and to > simultaneously install symlinks for their current names, so that nothing > breaks. > I don't really understand what issue are we trying to solve here. Can someone describe a scenario where this (name of the binary not clearly indicating it's related postgres) causes issues in practice? On my system, there are ~1400 binaries in /usr/bin, and for the vast majority of them it's rather unclear where do they come from. But it's not really an issue, because we have tools to do that 1) man 2) -h/--help 3) rpm -qf $file (and similarly for other packagers) 4) set --prefix to install binaries so separate directory (which some distros already do anyway) So to me this seems like a fairly invasive change (potentially breaking quite a few scripts/tools) just to address a minor inconvenience. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 2019-Mar-20, Andres Freund wrote: > On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: > > If we are evaluating this whole symlink / renaming thing, there could be > > arguments for a "pgsql" alias to psql (or vice versa), but I don't think > > "pg_sql" makes any sense and could be fairly confusing. > > I don't care much about createdb etc, but I'm *strongly* against > renaming psql and/or adding symlinks. +1. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
On 3/20/19 3:19 PM, Andres Freund wrote: > Hi, > > On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: >> If we are evaluating this whole symlink / renaming thing, there could be >> arguments for a "pgsql" alias to psql (or vice versa), but I don't think >> "pg_sql" makes any sense and could be fairly confusing. > > I don't care much about createdb etc, but I'm *strongly* against > renaming psql and/or adding symlinks. That's like 95% of all > interactions people have with postgres binaries, making that more > confusing would be an enterily unnecessary self own. Yeah I agree. The only one I would entertain is "pgsql" given enough people refer to PostgreSQL as such, but note I use the term "entertain" in a similar way to when I knowingly watch terrible movies. Jonathan signature.asc Description: OpenPGP digital signature
Re: PostgreSQL pollutes the file system
Hi, On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote: > If we are evaluating this whole symlink / renaming thing, there could be > arguments for a "pgsql" alias to psql (or vice versa), but I don't think > "pg_sql" makes any sense and could be fairly confusing. I don't care much about createdb etc, but I'm *strongly* against renaming psql and/or adding symlinks. That's like 95% of all interactions people have with postgres binaries, making that more confusing would be an enterily unnecessary self own. Greetings, Andres Freund
Re: PostgreSQL pollutes the file system
On 3/20/19 2:11 PM, Tom Lane wrote: > "Fred .Flintstone" writes: >> Even just creating symlinks would be a welcome change. >> So the real binary is pg_foo and foo is a symoblic link that points to >> pg_foo. >> Then at least I can type pg_ and use tab auto-completion to find >> everything related to PostgreSQL. > > You'd miss psql. I think the odds of renaming psql are not > distinguishable from zero: whatever arguments you might want to make > about, say, renaming initdb perhaps not affecting too many scripts > are surely not going to fly for psql. So that line of argument > isn't too convincing. To add to that, for better or worse, many people associate the PostgreSQL database itself as "psql" or "pgsql" ("I use psql, it's my favorite database!"). If we are evaluating this whole symlink / renaming thing, there could be arguments for a "pgsql" alias to psql (or vice versa), but I don't think "pg_sql" makes any sense and could be fairly confusing. Jonathan signature.asc Description: OpenPGP digital signature
Re: PostgreSQL pollutes the file system
On 3/20/19 2:08 PM, Alvaro Herrera wrote: > On 2019-Mar-20, Euler Taveira wrote: > >> Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: >>> >>> We managed to get rid of createlang and droplang in v10, and there >>> hasn't been that much push-back about it. So maybe there could be >>> a move to remove createuser/dropuser? Or at least rename them to >>> pg_createuser and pg_dropuser. But I think this was discussed >>> (again) during the v10 cycle, and we couldn't agree to do more than >>> get rid of createlang/droplang. > > Previous discussion: > https://postgr.es/m/CABUevExPrfPH5K5qM=zst7tvfyace+i5qja6bfwckkyrh8m...@mail.gmail.com > >> Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I >> said in the other email). However, if we don't have sufficient votes, >> let's at least consider a 'pg_' prefix. > > I vote to keep these rename these utilities to have a pg_ prefix and to > simultaneously install symlinks for their current names, so that nothing > breaks. This sounds like a reasonable plan, pending which binaries we feel to do that with. Pardon this naive question as I have not used such systems in awhile, but would this work on systems that do not support symlinks? Jonathan signature.asc Description: OpenPGP digital signature
Re: PostgreSQL pollutes the file system
On 3/20/19 9:32 PM, Alvaro Herrera wrote: On 2019-Mar-20, Fred .Flintstone wrote: Even just creating symlinks would be a welcome change. So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. Then at least I can type pg_ and use tab auto-completion to find everything related to PostgreSQL. There is merit to this argument; if the starting point is an unknown file /usr/bin/foo, then having it be a symlink to /usr/bin/pg_foo makes it clear which package it belongs to. We don't *have to* get rid of the symlinks any time soon, but installing as symlinks now will allow Skynet to get rid of them some decades from now. +1 to tasking Skynet with removing deprecated features. Seems like it would save a lot of arguing. -- -David da...@pgmasters.net
Re: PostgreSQL pollutes the file system
"Fred .Flintstone" writes: > Even just creating symlinks would be a welcome change. > So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. > Then at least I can type pg_ and use tab auto-completion to find > everything related to PostgreSQL. You'd miss psql. I think the odds of renaming psql are not distinguishable from zero: whatever arguments you might want to make about, say, renaming initdb perhaps not affecting too many scripts are surely not going to fly for psql. So that line of argument isn't too convincing. regards, tom lane
Re: PostgreSQL pollutes the file system
On Wed, 20 Mar 2019 13:56:55 -0400 Tom Lane wrote: > Julien Rouhaud writes: > > On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira > > wrote: > >> createdb, dropdb, createuser, dropuser, reindexdb are binaries that > >> confuse most newbies. Which tool is theses binaries from? The names > >> does not give a hint. How often those confusing name tools are used? > > > initdb is probably an order of magnitude worse name than all of these. > > Meh. The ones with "db" in the name don't strike me as mortal sins; > even if you don't recognize them as referring to a "database", you're > not likely to guess wrongly that you know what they do. The two that > seem the worst to me are createuser and dropuser, which not only have > no visible connection to "postgres" or "database" but could easily > be mistaken for utilities for managing operating-system accounts. > > We managed to get rid of createlang and droplang in v10, and there > hasn't been that much push-back about it. So maybe there could be > a move to remove createuser/dropuser? Or at least rename them to > pg_createuser and pg_dropuser. If you rename them, rename as pg_createrole and pg_droprole :) I teach people not to use "CREATE USER/GROUP", but each time I have to tell them "Yes, we kept createuser since 8.1 where roles has been introduced for backward compatibility. No, there's no createrole". ++
Re: PostgreSQL pollutes the file system
On 2019-Mar-20, Euler Taveira wrote: > Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: > > > > We managed to get rid of createlang and droplang in v10, and there > > hasn't been that much push-back about it. So maybe there could be > > a move to remove createuser/dropuser? Or at least rename them to > > pg_createuser and pg_dropuser. But I think this was discussed > > (again) during the v10 cycle, and we couldn't agree to do more than > > get rid of createlang/droplang. Previous discussion: https://postgr.es/m/CABUevExPrfPH5K5qM=zst7tvfyace+i5qja6bfwckkyrh8m...@mail.gmail.com > Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I > said in the other email). However, if we don't have sufficient votes, > let's at least consider a 'pg_' prefix. I vote to keep these rename these utilities to have a pg_ prefix and to simultaneously install symlinks for their current names, so that nothing breaks. [In a couple of releases we could patch them so that they print a deprecation warning to stderr if they're invoked without the prefix.] -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PostgreSQL pollutes the file system
Em qua, 20 de mar de 2019 às 14:57, Tom Lane escreveu: > > We managed to get rid of createlang and droplang in v10, and there > hasn't been that much push-back about it. So maybe there could be > a move to remove createuser/dropuser? Or at least rename them to > pg_createuser and pg_dropuser. But I think this was discussed > (again) during the v10 cycle, and we couldn't agree to do more than > get rid of createlang/droplang. > Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I said in the other email). However, if we don't have sufficient votes, let's at least consider a 'pg_' prefix. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Re: PostgreSQL pollutes the file system
Julien Rouhaud writes: > On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira wrote: >> createdb, dropdb, createuser, dropuser, reindexdb are binaries that >> confuse most newbies. Which tool is theses binaries from? The names >> does not give a hint. How often those confusing name tools are used? > initdb is probably an order of magnitude worse name than all of these. Meh. The ones with "db" in the name don't strike me as mortal sins; even if you don't recognize them as referring to a "database", you're not likely to guess wrongly that you know what they do. The two that seem the worst to me are createuser and dropuser, which not only have no visible connection to "postgres" or "database" but could easily be mistaken for utilities for managing operating-system accounts. We managed to get rid of createlang and droplang in v10, and there hasn't been that much push-back about it. So maybe there could be a move to remove createuser/dropuser? Or at least rename them to pg_createuser and pg_dropuser. But I think this was discussed (again) during the v10 cycle, and we couldn't agree to do more than get rid of createlang/droplang. regards, tom lane
Re: PostgreSQL pollutes the file system
On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira wrote: > > createdb, dropdb, createuser, dropuser, reindexdb are binaries that > confuse most newbies. Which tool is theses binaries from? The names > does not give a hint. How often those confusing name tools are used? initdb is probably an order of magnitude worse name than all of these.
Re: PostgreSQL pollutes the file system
On 2019-Mar-20, Fred .Flintstone wrote: > Even just creating symlinks would be a welcome change. > So the real binary is pg_foo and foo is a symoblic link that points to pg_foo. > Then at least I can type pg_ and use tab auto-completion to find > everything related to PostgreSQL. There is merit to this argument; if the starting point is an unknown file /usr/bin/foo, then having it be a symlink to /usr/bin/pg_foo makes it clear which package it belongs to. We don't *have to* get rid of the symlinks any time soon, but installing as symlinks now will allow Skynet to get rid of them some decades from now. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services