On 10/17/2014 10:43 AM, Magnus Hagander wrote:
> On Fri, Oct 17, 2014 at 12:41 AM, Josh Berkus <josh@agliodbs.com> wrote:
>> Is there any possible way to fix the command database
>> so that users don't get that error message?
Looking at the command-not-found sources, there doesn't seem to be any
kind of rule system or exceptions. It's just an index (not even a stupid
one, correcting spelling errors and such. But if you ask for pg_ctl,
that's a perfect match.)
Extending the search paths to include /usr/lib/postgresql/X.Y/bin in the
index wouldn't help, as these directories usually aren't in the PATH.
(And postgresql-X.Y is likely to be installed already, in that situation.)
What command-not-found could probably do instead is taking those
(installed) executables into account and propose to use them.
> That does indeed sound like a packaging issue with postgres-xc. It
> shouldn't expose a non-versioned pg_ctl, the same way that regular
> PostgreSQL doesn't.
That sounds like a good idea independent of this issue. Ideally, making
Postgres-XC (and Postgres-XL...) co-installable with vanilla Postgres
versions. Also seems like a substantial amount of work, though.
>> to date I've witnessed four postgres beginners then trying to
>> install postgres-xc and really messing up their servers.
Granted, the advice is unfortunate. However, given postgres-xc conflicts
with postgresql-common, the package manager would have to ask about
uninstalling postgresql-common and all dependent Postgres packages. That
would raise a couple of red flags for me. So I'm also a bit surprised
people manage to screw their systems that way... AKA: It ain't broken
*that* badly.
Another, simplistic idea: Given these packages currently conflict, could
(and should) postgresql-common provide a wrapper or dummy /usr/bin/pg_ctl?
Regards
Markus Wanner
