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 s
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
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 surprisingly
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 while
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
su
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 f
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 fragi
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. Relyi
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 tha
>>> 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 n
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
--
Eu
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
i
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 any
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 woul
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.
On Wed, Apr 10, 2019 at 3:10 PM Christoph Berg wrote:
>
> Re: Fred
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 d
> 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 w
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 ol
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 t
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 Developmen
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
> > > fac
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 wa
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-t
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.
Re: Pavel Stehule 2019-03-29
> > 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.
"Prepared" in the sense of what format() does.
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 r
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
> > just
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
> ju
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
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. O
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 ev
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 to
> 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, w
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 symlin
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 pg_create
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 t
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 exis
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 cr
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
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 wi
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-cen
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,
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 diffe
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.
>> That
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
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 V
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. W
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 T
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/b
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/
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 can
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 thi
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_ pref
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 e
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 escrev
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 welcom
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.
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 Herreraht
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 ~14
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.
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, ther
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 bec
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
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'
> 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 the
>> +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 th
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
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 co
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 created
On 2019-03-20 15:13:00 -0400, Jonathan S. Katz wrote:
> Pardon this naive question as I have not used such systems in awhile,
> but would this work on systems that do not support symlinks?
We can just copy the binaries there, they're not that big anyway.
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
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
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 rel
"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
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 re
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. B
1 - 100 of 113 matches
Mail list logo
