>>> 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
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 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
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 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
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
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 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
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
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
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
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?
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
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 3/19/19 11:19 AM, Fred .Flintstone wrote:
PostgreSQL pollutes the file system with lots of binaries that it is
not obvious that they belong to PostgreSQL.
Such as "/usr/bin/createdb", etc.
It would be better if these files were renamed to be prefixed with
pg_, such as pg_created
On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson wrote:
> On 3/19/19 11:19 AM, Fred .Flintstone wrote:
> > PostgreSQL pollutes the file system with lots of binaries that it is
> > not obvious that they belong to PostgreSQL.
> >
> > Such as "/usr/bin/createdb"
1:19 AM, Fred .Flintstone wrote:
> > PostgreSQL pollutes the file system with lots of binaries that it is
> > not obvious that they belong to PostgreSQL.
> >
> > Such as "/usr/bin/createdb", etc.
> >
> > It would be better if these files were renamed to be prefi
t" command.
The wrapper script addition doesn't mean executing the commands
directly without the wrapper won't be possible. So one doesn't exclude
the other.
It would be a welcome addition.
On Wed, Mar 20, 2019 at 11:05 AM Andreas Karlsson wrote:
On 3/19/19 11:19 AM, Fred .Flin
Chris Travers writes:
> On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson wrote:
>> On 3/19/19 11:19 AM, Fred .Flintstone wrote:
>>> It would be better if these files were renamed to be prefixed with
>>> pg_, such as pg_createdb.
>>> Or even better postgresql-createdb then be reachable by through
>>> This topic has been discussed before e.g. in 2008 in
>>> https://www.postgresql.org/message-id/47EA5CC0.8040102%40sun.com and
>>> also more recently but I cannot find it in the archives right now.
>
> And also before that, eg
> https://www.postgresql.org/message-id/flat/199910091253.IAA10670%4
On Wed, Mar 20, 2019 at 3:19 PM Tom Lane wrote:
> If we didn't pull the trigger twenty years ago, nor ten years ago,
> we're not likely to do so now. Yeah, it's a mess and we'd certainly
> do it differently if we were starting from scratch, but we're not
> starting from scratch. There are decade
Em qua, 20 de mar de 2019 às 11:39, Tatsuo Ishii escreveu:
>
> +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,
Em qua, 20 de mar de 2019 às 14:22, Fred .Flintstone
escreveu:
>
> 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 Post
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 t
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
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?
> in
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
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
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
"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 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
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 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 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.
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 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
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 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
>> +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
> 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
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'
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
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
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
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.
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 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 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.
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
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
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.
>
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
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
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 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
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 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
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
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
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
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
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
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 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
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
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 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
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,
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 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
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 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
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 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 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
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 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
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
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
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
> 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
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
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
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?
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
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 -
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
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
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
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
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
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
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: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: 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: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
> >> 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 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
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 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
101 - 200 of 226 matches
Mail list logo