Thread: Command tags in create/drop scripts
The messages output by the "scripts" always seemed unnecessary to me, e.g., $ createdb foo CREATE DATABASE A Unix program (hi Magnus) shouldn't need to say anything if the requested action succeeded. I believe the history of this output is actually that these scripts simply used to call psql and no one really questioned why the output should be this way. There are also some inconsistencies, e.g., createlang doesn't output anything, and createuser outputs CREATE ROLE. I would just remove all this, but I suppose this will be controversial? -- Peter Eisentraut http://developer.postgresql.org/~petere/
On 5/31/07, Peter Eisentraut <peter_e@gmx.net> wrote:
Can it me made to return an integer like most UNIX commands do? This helps immensely when writing shell scripts.
Thanks!
The messages output by the "scripts" always seemed unnecessary to me, e.g.,
$ createdb foo
CREATE DATABASE
A Unix program (hi Magnus) shouldn't need to say anything if the requested
action succeeded.
I believe the history of this output is actually that these scripts simply
used to call psql and no one really questioned why the output should be this
way. There are also some inconsistencies, e.g., createlang doesn't output
anything, and createuser outputs CREATE ROLE.
I would just remove all this, but I suppose this will be controversial?
Can it me made to return an integer like most UNIX commands do? This helps immensely when writing shell scripts.
Thanks!
"CAJ CAJ" <pguser@gmail.com> writes:
> Can it me made to return an integer like most UNIX commands do? This helps
> immensely when writing shell scripts.
Don't they do that already? If not, that's a bug quite independent of
Peter's cosmetic concern.
regards, tom lane
On 5/31/07, CAJ CAJ <pguser@gmail.com> wrote:
> Can it me made to return an integer like most UNIX commands do? This helps
> immensely when writing shell scripts.
Don't they do that already? If not, that's a bug quite independent of
Peter's cosmetic concern.
Ah, I just tested it. create/drop user commands does return an integer. It's not mentioned in the manpages though.
BTW, there is a "-q" option to quieten the output.
Peter Eisentraut wrote: > The messages output by the "scripts" always seemed unnecessary to me, e.g., > > $ createdb foo > CREATE DATABASE > > A Unix program (hi Magnus) shouldn't need to say anything if the requested > action succeeded. > > I believe the history of this output is actually that these scripts simply > used to call psql and no one really questioned why the output should be this > way. There are also some inconsistencies, e.g., createlang doesn't output > anything, and createuser outputs CREATE ROLE. > > I would just remove all this, but I suppose this will be controversial? Removal of the tags is fine with me. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Peter Eisentraut wrote:
> The messages output by the "scripts" always seemed unnecessary to me, e.g.,
>
> $ createdb foo
> CREATE DATABASE
>
> A Unix program (hi Magnus) shouldn't need to say anything if the requested
> action succeeded.
>
> I believe the history of this output is actually that these scripts simply
> used to call psql and no one really questioned why the output should be this
> way. There are also some inconsistencies, e.g., createlang doesn't output
> anything, and createuser outputs CREATE ROLE.
>
> I would just remove all this, but I suppose this will be controversial?
And what about replace all "scripts" by one command e.g pg_cmd with
following interface:
pg_cmd create database <...> create role ... drop database ... list database
...
It solves potential name collision (for example createuser should
collide with other unix command) and output is easy maintainable in one
application.
Zdenek
Zdenek Kotala wrote: > > And what about replace all "scripts" by one command e.g pg_cmd with > following interface: > > pg_cmd create database <...> > create role ... > drop database ... > list database > ... > > > It solves potential name collision (for example createuser should > collide with other unix command) and output is easy maintainable in > one application. > > > And we'll break a million applications that rely on the command names. We really don't have the luxury of being able to revisit every design decision that's ever been made. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Zdenek Kotala wrote:
>> And what about replace all "scripts" by one command e.g pg_cmd with
>> following interface:
>>
>> pg_cmd create database <...>
> And we'll break a million applications that rely on the command names.
If you want that, it already exists: it's pronounced "psql -c ...".
regards, tom lane
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Zdenek Kotala wrote:
>>> And what about replace all "scripts" by one command e.g pg_cmd with
>>> following interface:
>>>
>>> pg_cmd create database <...>
>
>> And we'll break a million applications that rely on the command names.
Compatibility is possible solve with parsing arg[0]. If old name appears
there command line will be parsed in old style... This functionally
should keep there for some transition interval. Packager will be
responsible if he create links for backward compatibility or not.
> If you want that, it already exists: it's pronounced "psql -c ...".
No, it is not solution, because you still have binaries with strange
names (e.g. createuser) on the disk.
Zdenek
Zdenek Kotala wrote: > Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> Zdenek Kotala wrote: >>>> And what about replace all "scripts" by one command e.g pg_cmd with >>>> following interface: >>>> >>>> pg_cmd create database <...> >> >>> And we'll break a million applications that rely on the command names. > > Compatibility is possible solve with parsing arg[0]. If old name > appears there command line will be parsed in old style... This > functionally should keep there for some transition interval. Packager > will be responsible if he create links for backward compatibility or not. Well, I don't think rolling up the miscellaneous commands into a single binary with behaviour dependent on arg[0] is a bad idea. I don't think it's something to be looked at during feature freeze, though, especially given our backlog. I think we'd need a good long lead time before we removed the old names from our default install - at least one release cycle, so it would be two years or more before this became any sort of reality. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Zdenek Kotala wrote:
>>>> And what about replace all "scripts" by one command e.g pg_cmd with
>>>> following interface:
> Well, I don't think rolling up the miscellaneous commands into a single
> binary with behaviour dependent on arg[0] is a bad idea.
I don't think that responds to Zdenek's complaint though. He's unhappy
about polluting /usr/bin with commands like "createuser" --- which is
not an unreasonable gripe. AFAICS it doesn't help if "createuser"
is a link to a single executable rather than a file of its own.
But in the light of backwards-compatibility requirements, I can't see us
removing "createuser" from the distribution ... not in 8.4, nor several
releases thereafter.
Sun's certainly free to not ship createuser in their packaging of PG,
and see what sort of push-back they get.
regards, tom lane
Tom Lane napsal(a):
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Zdenek Kotala wrote:
>>>>> And what about replace all "scripts" by one command e.g pg_cmd with
>>>>> following interface:
>
>> Well, I don't think rolling up the miscellaneous commands into a single
>> binary with behaviour dependent on arg[0] is a bad idea.
>
> I don't think that responds to Zdenek's complaint though. He's unhappy
> about polluting /usr/bin with commands like "createuser" --- which is
> not an unreasonable gripe. AFAICS it doesn't help if "createuser"
> is a link to a single executable rather than a file of its own.
Yes, It was one idea (after midnight :-) how to keep backward
compatibility for next few releases, but better solution is keep old
binaries for couple of release cycles.
> But in the light of backwards-compatibility requirements, I can't see us
> removing "createuser" from the distribution ... not in 8.4, nor several
> releases thereafter.
I agree, I only want to start discussion about new command which will
replace old binaries. Old binaries will be marked as obsolete and they
will be removed e.g. in 9.0. Until we do not have the new command we can
not start thinking about remove old one. I think we can have new command
ready for 8.4.
Zdenek
Is this a TODO? --------------------------------------------------------------------------- Zdenek Kotala wrote: > Tom Lane napsal(a): > > Andrew Dunstan <andrew@dunslane.net> writes: > >> Zdenek Kotala wrote: > >>>>> And what about replace all "scripts" by one command e.g pg_cmd with > >>>>> following interface: > > > >> Well, I don't think rolling up the miscellaneous commands into a single > >> binary with behaviour dependent on arg[0] is a bad idea. > > > > I don't think that responds to Zdenek's complaint though. He's unhappy > > about polluting /usr/bin with commands like "createuser" --- which is > > not an unreasonable gripe. AFAICS it doesn't help if "createuser" > > is a link to a single executable rather than a file of its own. > > Yes, It was one idea (after midnight :-) how to keep backward > compatibility for next few releases, but better solution is keep old > binaries for couple of release cycles. > > > But in the light of backwards-compatibility requirements, I can't see us > > removing "createuser" from the distribution ... not in 8.4, nor several > > releases thereafter. > > I agree, I only want to start discussion about new command which will > replace old binaries. Old binaries will be marked as obsolete and they > will be removed e.g. in 9.0. Until we do not have the new command we can > not start thinking about remove old one. I think we can have new command > ready for 8.4. > > > Zdenek > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Is this a TODO?
I don't think so; there is no demand from anybody but Zdenek to remove
those programs. Has it ever even come up before?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Is this a TODO? > > I don't think so; there is no demand from anybody but Zdenek to remove > those programs. Has it ever even come up before? No. Agreed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
It's always seemed a little odd to me that Postgres should install a
command called "createuser" or "createlang", because it's entirely
non-obvious on first examination that these commands (which often live
in /usr/bin) have any connections with PostgreSQL. Shouldn't there be
at least be a "pg" in the name somewhere?
...Robert
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Monday, June 04, 2007 10:31 AM
To: Bruce Momjian
Cc: Zdenek Kotala; Andrew Dunstan; Peter Eisentraut;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Command tags in create/drop scripts
Bruce Momjian <bruce@momjian.us> writes:
> Is this a TODO?
I don't think so; there is no demand from anybody but Zdenek to remove
those programs. Has it ever even come up before?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Is this a TODO?
>
> I don't think so; there is no demand from anybody but Zdenek to remove
> those programs. Has it ever even come up before?
>
Tom, Bruce
I started with postgres 6.5 as administrator and from this version names
of these utilities have been for me little bit confusing and annoying. I
have hoped that it will be changed in the future. It is my personal
feeling since 1999. I prefer to add on TODO list and also question is
why we don't have:
"pg_ctl -D <path> init" instead of initdb command?
Zdenek
Zdenek Kotala wrote: > Tom Lane wrote: > >Bruce Momjian <bruce@momjian.us> writes: > >>Is this a TODO? > > > >I don't think so; there is no demand from anybody but Zdenek to remove > >those programs. Has it ever even come up before? Personally I found really strange to have "createuser" and "createdb" shipped by Postgres when I started using it. I just didn't complain. > "pg_ctl -D <path> init" instead of initdb command? Seems a reasonable thing to do too. Harder to type for developers, but how much of a problem this is for real users? And developers can script the thing anyway so I don't think this is a real problem. One idea is to move the offending binaries into libexec, and have pg_ctl or other helpers (pg_cmd) call them; and where compatibility with the old versions is requested, create symlinks in bindir. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Jun 5, 9:19 am, alvhe...@commandprompt.com (Alvaro Herrera) wrote: > Zdenek Kotala wrote: > > Tom Lane wrote: > > >Bruce Momjian <b...@momjian.us> writes: > > >>Is this a TODO? > > > >I don't think so; there is no demand from anybody but Zdenek to remove > > >those programs. Has it ever even come up before? > > Personally I found really strange to have "createuser" and "createdb" > shipped by Postgres when I started using it. I just didn't complain. +1. Given the prevalence of the pg_foo convention, those names are clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest simply renaming to pg_createuser and friends with the same command line options as the originals. Have the binaries check $0 and emit a warning about using the deprecated name to STDERR if called by a name that doesn't have the pg_ prefix. Default to symlinking the old names for backwards compatibility until 9.0. Andrew
On Tue, Jun 05, 2007 at 05:52:39PM -0000, Andrew Hammond wrote: > On Jun 5, 9:19 am, alvhe...@commandprompt.com (Alvaro Herrera) wrote: > > Zdenek Kotala wrote: > > > Tom Lane wrote: > > > >Bruce Momjian <b...@momjian.us> writes: > > > >>Is this a TODO? > > > > > >I don't think so; there is no demand from anybody but Zdenek to remove > > > >those programs. Has it ever even come up before? > > > > Personally I found really strange to have "createuser" and "createdb" > > shipped by Postgres when I started using it. I just didn't complain. > > +1. Given the prevalence of the pg_foo convention, those names are > clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest > simply renaming to pg_createuser and friends with the same command > line options as the originals. Have the binaries check $0 and emit a > warning about using the deprecated name to STDERR if called by a name > that doesn't have the pg_ prefix. Default to symlinking the old names > for backwards compatibility until 9.0. +1 -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote:
> On Tue, Jun 05, 2007 at 05:52:39PM -0000, Andrew Hammond wrote:
>> On Jun 5, 9:19 am, alvhe...@commandprompt.com (Alvaro Herrera) wrote:
>>> Zdenek Kotala wrote:
>>>> Tom Lane wrote:
>>>>> Bruce Momjian <b...@momjian.us> writes:
>>>>>> Is this a TODO?
>>>>> I don't think so; there is no demand from anybody but Zdenek to remove
>>>>> those programs. Has it ever even come up before?
>>> Personally I found really strange to have "createuser" and "createdb"
>>> shipped by Postgres when I started using it. I just didn't complain.
>> +1. Given the prevalence of the pg_foo convention, those names are
>> clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest
>> simply renaming to pg_createuser and friends with the same command
>> line options as the originals. Have the binaries check $0 and emit a
>> warning about using the deprecated name to STDERR if called by a name
>> that doesn't have the pg_ prefix. Default to symlinking the old names
>> for backwards compatibility until 9.0.
>
> +1
+1
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Jim C. Nasby wrote:
>> On Tue, Jun 05, 2007 at 05:52:39PM -0000, Andrew Hammond wrote:
>>> +1. Given the prevalence of the pg_foo convention, those names are
>>> clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest
>>> simply renaming to pg_createuser and friends with the same command
>>> line options as the originals. Have the binaries check $0 and emit a
>>> warning about using the deprecated name to STDERR if called by a name
>>> that doesn't have the pg_ prefix. Default to symlinking the old names
>>> for backwards compatibility until 9.0.
>>
>> +1
> +1
I like this better than the original proposal, too. Doing more than
this seems like more work and more confusion for users than the problem
justifies.
regards, tom lane
On Fri, Jun 08, 2007 at 08:12:22PM -0500, Jim C. Nasby wrote: > On Tue, Jun 05, 2007 at 05:52:39PM -0000, Andrew Hammond wrote: > > On Jun 5, 9:19 am, alvhe...@commandprompt.com (Alvaro Herrera) wrote: > > > Zdenek Kotala wrote: > > > > Tom Lane wrote: > > > > >Bruce Momjian <b...@momjian.us> writes: > > > > >>Is this a TODO? > > > > > > > >I don't think so; there is no demand from anybody but Zdenek to remove > > > > >those programs. Has it ever even come up before? > > > > > > Personally I found really strange to have "createuser" and "createdb" > > > shipped by Postgres when I started using it. I just didn't complain. > > > > +1. Given the prevalence of the pg_foo convention, those names are > > clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest > > simply renaming to pg_createuser and friends with the same command > > line options as the originals. Have the binaries check $0 and emit a > > warning about using the deprecated name to STDERR if called by a name > > that doesn't have the pg_ prefix. Default to symlinking the old names > > for backwards compatibility until 9.0. > > +1 +1 It's a lot easier just to prefix the names than to do something "clever." Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
David Fetter wrote:
> On Fri, Jun 08, 2007 at 08:12:22PM -0500, Jim C. Nasby wrote:
>> On Tue, Jun 05, 2007 at 05:52:39PM -0000, Andrew Hammond wrote:
>>> On Jun 5, 9:19 am, alvhe...@commandprompt.com (Alvaro Herrera) wrote:
>>>> Zdenek Kotala wrote:
>>>>> Tom Lane wrote:
>>>>>> Bruce Momjian <b...@momjian.us> writes:
>>>>>>> Is this a TODO?
>>>>>> I don't think so; there is no demand from anybody but Zdenek to remove
>>>>>> those programs. Has it ever even come up before?
>>>> Personally I found really strange to have "createuser" and "createdb"
>>>> shipped by Postgres when I started using it. I just didn't complain.
>>> +1. Given the prevalence of the pg_foo convention, those names are
>>> clunky. So is initdb. I'm less creative than Zdenek, so I'd suggest
>>> simply renaming to pg_createuser and friends with the same command
>>> line options as the originals. Have the binaries check $0 and emit a
>>> warning about using the deprecated name to STDERR if called by a name
>>> that doesn't have the pg_ prefix. Default to symlinking the old names
>>> for backwards compatibility until 9.0.
>> +1
>
> +1
>
> It's a lot easier just to prefix the names than to do something
> "clever."
I agree that it is easier to implement. But my original idea was create one command which should be easy expandable.
Forexample add LIST
command which it allow to get list of users, roles, langs, databases
(instead of psql -l). There is also no way how to create table space?
Will we add command pg_createtablespace ? I think better is keep it in
one binary instead extend list of deliverable object.
I think for people is better to remember pg_cmd --help instead looking
for pg_something command. And a lot of code is share anyway. The nice
example is ZFS implementation. You need only know two commands (ZPOOL
and ZFS) to configure everything include NFS sharing.
Zdenek
Added to TODO: * Prefix command-line utilities like createuser with 'pg_' http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php --------------------------------------------------------------------------- Alvaro Herrera wrote: > Zdenek Kotala wrote: > > Tom Lane wrote: > > >Bruce Momjian <bruce@momjian.us> writes: > > >>Is this a TODO? > > > > > >I don't think so; there is no demand from anybody but Zdenek to remove > > >those programs. Has it ever even come up before? > > Personally I found really strange to have "createuser" and "createdb" > shipped by Postgres when I started using it. I just didn't complain. > > > "pg_ctl -D <path> init" instead of initdb command? > > Seems a reasonable thing to do too. Harder to type for developers, but > how much of a problem this is for real users? And developers can script > the thing anyway so I don't think this is a real problem. > > One idea is to move the offending binaries into libexec, and have pg_ctl > or other helpers (pg_cmd) call them; and where compatibility with the > old versions is requested, create symlinks in bindir. > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > The PostgreSQL Company - Command Prompt, Inc. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +