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
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
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?
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
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
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
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
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
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
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
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
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.
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
>>> 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
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
--
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
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
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
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
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
> 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
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
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
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
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
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
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
> > >
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
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
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
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
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.
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
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
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
> >
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
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
>
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
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
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.
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?
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
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
> 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,
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
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
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
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
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
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
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
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
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
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.
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
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
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_
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
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
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
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
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.
>>
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
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
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
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.
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
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
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
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
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
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_
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
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.
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
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
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
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 Herrera
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
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
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,
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
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
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
> 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
>> +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
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
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
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
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
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
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
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
"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
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
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
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.
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?
>
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
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
1 - 100 of 109 matches
Mail list logo
