Re: New 'pg' consolidated metacommand patch

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: New 'pg' consolidated metacommand patch
Date: 2020-05-27 14:06:15
Message-ID: 5AEBAC33-1523-4DAD-80DC-DE9B30F64616@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On May 27, 2020, at 1:13 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> Hi
>
> On Wed, May 27, 2020 at 12:19 AM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> I think it makes sense that packagers could put the LIBEXECDIR in the PATH so that 3rd-party scripts which call pg_ctl, initdb, etc. continue to work.
>
> Having packages that futz with the PATH is generally a bad idea, especially those that support side-by-side installations of different versions. None of ours (EDBs) will be doing so.

I probably phrased that badly. The operative word in that sentence was "could". If we rename the binaries, people can still make links to them from the old name, but if we don't rename them, then either links or PATH changes *could* be used. I'm not trying to recommend any particular approach. Mentioning "packagers" probably wasn't helpful, as "people" works just as well in that sentence.

There is also the option of not moving the binaries at all, and only putting new commands into libexec, while grandfathering existing ones in bin.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2020-05-27 14:20:14 Re: New 'pg' consolidated metacommand patch
Previous Message Mark Dilger 2020-05-27 14:00:35 Re: New 'pg' consolidated metacommand patch