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
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 |