Обсуждение: Renaming some binaries
Hi, I'm bringing this $subject into discussion again. Historically, we are carrying binary names that have been confused newbies. createuser is the worst name so for. Also, names like createdb, initdb, reindexdb, and droplang does not suggest what product it is referring to. Adding a prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus about this change, I suggest renaming the following binaries: clusterdb createdb createlang createuser dropdb droplang dropuser initdb oid2name reindexdb vacuumdb vacuumlo Another major change related to this topic is assemble functionalities from binaries. We currently have 34 binaries (is that a lot for a single software?). Also, some of them have the same principle: execute a administrative or maintenance command. IMHO, from the list above, we could reduce it to: pg_command: clusterdb, createdb, dropdb, createuser, dropuser, createlang, droplang, reindexdb, vacuumdb, vacuumlo. It also has the advantage to allow adding new administrative/maintenance commands to it in the future; pg_oid2name: I don't have a strong opinion that it fits in pg_command; initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. Opinions? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte24x7 e Treinamento
On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote: > Hi, > > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and > droplang does not suggest what product it is referring to. Adding a > prefix (pg_, pg, ...) would 'make things clear'. +1 for pg_ . We should have done this long ago, but this is better fixed than left broken. > If we have a consensus > about this change, I suggest renaming the following binaries: > > clusterdb > createdb > createlang > createuser > dropdb > droplang > dropuser > initdb > oid2name > reindexdb > vacuumdb > vacuumlo > > Another major change related to this topic is assemble functionalities > from binaries. We currently have 34 binaries (is that a lot for a single > software?). Also, some of them have the same principle: execute a > administrative or maintenance command. IMHO, from the list above, we > could reduce it to: > > pg_command: clusterdb, createdb, dropdb, createuser, dropuser, > createlang, droplang, reindexdb, vacuumdb, vacuumlo. It also has the > advantage to allow adding new administrative/maintenance commands to it > in the future; Would these make sense as pg_ctl options, or are you separating them out because they're not instance-wide? If separating them is important on those grounds, how about something like pg_db or pg_db_command? > pg_oid2name: I don't have a strong opinion that it fits in pg_command; I vaguely knew that this existed, but I can't recall having heard of anybody actually using it. I suppose it's under pg_ctl if the split above between instance-wide and db-specific holds. > initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. > > Opinions? +1 for removing initdb. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 26-08-2016 14:03, David Fetter wrote: > Would these make sense as pg_ctl options, or are you separating them > out because they're not instance-wide? If separating them is > important on those grounds, how about something like pg_db or > pg_db_command? > It doesn't make sense because pg_ctl is server-side and pg_command would be client-side. >> pg_oid2name: I don't have a strong opinion that it fits in pg_command; > > I vaguely knew that this existed, but I can't recall having heard of > anybody actually using it. I suppose it's under pg_ctl if the split > above between instance-wide and db-specific holds. > I don't use it for a long time. It also a client-side binary then better place for it is pg_command. BTW, is anybody using it? If so, we could add this functionality to psql and remove it. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte24x7 e Treinamento
On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> wrote: > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and > droplang does not suggest what product it is referring to. Adding a > prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus > about this change, I suggest renaming the following binaries: > > clusterdb > createdb > createlang > createuser > dropdb > droplang > dropuser > initdb > oid2name > reindexdb > vacuumdb > vacuumlo Why not just remove them all and change the docs to suggest using psql -c "CREATE DATABASE foo" etc Less code, no confusion because we have just one client tool - psql. Almost all serious users will be issuing more than one DDL command at a time, so they'll be writing a script anyway. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2016-08-26 22:01:58 +0200, Simon Riggs wrote: > On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> wrote: > > > I'm bringing this $subject into discussion again. Historically, we are > > carrying binary names that have been confused newbies. createuser is the > > worst name so for. Also, names like createdb, initdb, reindexdb, and > > droplang does not suggest what product it is referring to. Adding a > > prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus > > about this change, I suggest renaming the following binaries: > > > > clusterdb > > createdb > > createlang > > createuser > > dropdb > > droplang > > dropuser > > initdb > > oid2name > > reindexdb > > vacuumdb > > vacuumlo > > Why not just remove them all and change the docs to suggest using > > psql -c "CREATE DATABASE foo" > etc > > Less code, no confusion because we have just one client tool - psql. Several of them have the ability to connect to several databases, some even do that in parallel.
On 2016-08-26 15:03, Andres Freund wrote: > On 2016-08-26 22:01:58 +0200, Simon Riggs wrote: >> On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> >> wrote: >> >> > I'm bringing this $subject into discussion again. Historically, we are >> > carrying binary names that have been confused newbies. createuser is the >> > worst name so for. Also, names like createdb, initdb, reindexdb, and >> > droplang does not suggest what product it is referring to. Adding a >> > prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus >> > about this change, I suggest renaming the following binaries: >> > >> > clusterdb >> > createdb >> > createlang >> > createuser >> > dropdb >> > droplang >> > dropuser >> > initdb >> > oid2name >> > reindexdb >> > vacuumdb >> > vacuumlo >> >> Why not just remove them all and change the docs to suggest using >> >> psql -c "CREATE DATABASE foo" >> etc >> >> Less code, no confusion because we have just one client tool - psql. > > Several of them have the ability to connect to several databases, some > even do that in parallel. vacuumdb being one that I've needed recently to do a number of DB's in a row. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
Simon Riggs wrote: > On 26 August 2016 at 18:26, Euler Taveira <euler@timbira.com.br> wrote: > > > I'm bringing this $subject into discussion again. Historically, we are > > carrying binary names that have been confused newbies. createuser is the > > worst name so for. Also, names like createdb, initdb, reindexdb, and > > droplang does not suggest what product it is referring to. Adding a > > prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus > > about this change, I suggest renaming the following binaries: > Why not just remove them all and change the docs to suggest using > > psql -c "CREATE DATABASE foo" I agree that some of these commands are redundant, and that we seem to have them just because we can, not because they provide useful functionality: createdb createlang createuser dropdb droplang dropuser I would rather have a single command that can do all those actions. We could have things like pg_ctl createuser I agree with Simon that many "serious users" would not be using the shell to implement this functionality, but something higher-level (a GUI, some web app) that's going to go through SQL instead. Still, for ad-hoc admin tasks it seems convenient to have the shell interface. Nowadays git and many other programs have a model where a single command (git) can call a number of different binaries which are not in PATH (/usr/lib/git-core in my installation). We could do something similar, where little else apart from pg_ctl, pg_dump, pgbench are in path, and most binaries are in some hidden binary directory known to pg_ctl. pg_ctl vacuum -j4 <database> (Personally, I very often have postmaster running on its own terminal with output to stderr. It'd be a little sad to lose that functionality, but what value does it offer to regular users? I can script my way around its lack, if needed.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 08/26/2016 07:03 PM, David Fetter wrote: > On Fri, Aug 26, 2016 at 01:26:39PM -0300, Euler Taveira wrote: >> Hi, >> ...>> >> initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. >> >> Opinions? > > +1 for removing initdb. > We can't just remove it because pg_ctl actually calls initdb, so we would have to move the code from src/bin/initdb to src/bin/pg_ctl. Which is doable, but I assume we'd also change how we pass parameters to it - right now we have to do this: pg_ctl init -o "... initdb params ..." But I assume we'd change this to regular parameters, if 'init' gets merged into pg_ctl - otherwise we'd force users to construct the param string only to immediately parse it (currently the "system()" call does that for us, but we'd have to implement that in pg_ctl). That however means that not only we break the scripts for all those calling initdb directly (and there's quite a few of them, I'm sure, exactly because it's simpler to pass the parameters directly), but also for all those already using pg_ctl. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Aug 26, 2016 at 04:33:47PM -0300, Euler Taveira wrote: > On 26-08-2016 14:03, David Fetter wrote: > > Would these make sense as pg_ctl options, or are you separating them > > out because they're not instance-wide? If separating them is > > important on those grounds, how about something like pg_db or > > pg_db_command? > > > It doesn't make sense because pg_ctl is server-side and pg_command would > be client-side. Perfect! > >> pg_oid2name: I don't have a strong opinion that it fits in pg_command; > > > > I vaguely knew that this existed, but I can't recall having heard of > > anybody actually using it. I suppose it's under pg_ctl if the split > > above between instance-wide and db-specific holds. > > > I don't use it for a long time. It also a client-side binary then better > place for it is pg_command. BTW, is anybody using it? If so, we could > add this functionality to psql and remove it. Sure. For server versions 10 or better, it could be a call to a new server-side function. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 2016-08-26 13:26:39 -0300, Euler Taveira wrote: > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and > droplang does not suggest what product it is referring to. Adding a > prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus > about this change, I suggest renaming the following binaries: > > clusterdb > createdb > createlang > createuser > dropdb > droplang > dropuser > initdb > oid2name > reindexdb > vacuumdb > vacuumlo Uhm, that'd need a careful backward compatibility plan, including a period of supporting both names. > Another major change related to this topic is assemble functionalities > from binaries. We currently have 34 binaries > (is that a lot for a single software?). Does it matter? The few bytes of disk space are essentially irrelevant. That said, on the code level, there'd be considerable benefit of coalescing: > pg_command: clusterdb, createdb, dropdb, createuser, dropuser, > createlang, droplang, reindexdb, vacuumdb, vacuumlo. these commands. We could do the old trick of leaving the old names as in place as symlinks. > initdb: we already have 'pg_ctl init' (since 9.0) and could remove > initdb. I fairly strongly against removing initdb as a separate binary. Issuies during cluster creation are already annoying to debug. This is a *significant* amount of work, it'll make backpatching a nightmare (although not that much happens in these binaries). I personally see better uses of my time. Andres
On 8/26/16 12:26 PM, Euler Taveira wrote: > initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. I have a concern specifically about pg_ctl. Depending on how your PostgreSQL is packaged, not all of the pg_ctl actions are safe or sensible to run. For example, if you are using systemd, then using pg_ctl restart will probably not do the right thing. And depending on SELinux (maybe), running initdb directly might also not do the right thing. In most cases, you can just not use pg_ctl and do all these things differently, but for example pg_ctl promote is the only documented way to do that thing. Until we have a better way to figure that out, I wouldn't want to put more things into pg_ctl, especially as the only way. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Aug 26, 2016 at 5:42 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 8/26/16 12:26 PM, Euler Taveira wrote: >> initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. > > I have a concern specifically about pg_ctl. Depending on how your > PostgreSQL is packaged, not all of the pg_ctl actions are safe or > sensible to run. For example, if you are using systemd, then using > pg_ctl restart will probably not do the right thing. And depending on > SELinux (maybe), running initdb directly might also not do the right > thing. In most cases, you can just not use pg_ctl and do all these > things differently, but for example pg_ctl promote is the only > documented way to do that thing. > > Until we have a better way to figure that out, I wouldn't want to put > more things into pg_ctl, especially as the only way. +1. Actually, my reasons for not wanting to put more stuff into pg_ctl are mostly different from yours, but I endorse the conclusion, at least. I think that it's just not going to be convenient. initdb is a complicated command with a bunch of options that are mostly all different from the options to pg_ctl. If we merge the two, then either pg_ctl has to be able to parse the initdb options and pass them through, or else you have to have some other convention for passing arguments through to initdb, like pg_ctl init -o "-X /ssd/foo" which is really not that much fun to remember or type, especially if the path has spaces in it and thus requires some kind of nested quoting. I do think it would make sense to add "pg_" to the beginning of all of most or all of the command names. And I do think it would make sense to just get rid of the scripts that don't do anything more than run a single command via psql. Binaries that offer additional functionality we might as well keep. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company