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
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
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
next time its needed, just to have to
return to the documentation again.
Preferably a wrapper around the tools could provide a summary for all
the tools, just like git --help.
On Fri, Apr 12, 2019 at 2:56 PM Daniel Gustafsson wrote:
>
> On Friday, April 12, 2019 2:25 PM, Fred .Flintston
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
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
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
>
> &
old name (symlink).
This seems technically feasible and easy.
How can we proceed?
On Tue, Apr 2, 2019 at 11:24 PM Fred .Flintstone wrote:
>
> It looks like this thread is featured on LWN under the article:
> Program names and "pollution".
> https://lwn.net/
> https:
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
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
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
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
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
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
what "createdb" does.
On Wed, Mar 27, 2019 at 2:51 PM Tomas Vondra
wrote:
>
> 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
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/
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
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 creati
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
otnet" 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 1
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_createdb.
Or even better postgresql-createdb then be reachable by t
22 matches
Mail list logo
