Re: pg_regress: lookup shellprog in $PATH

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Gurjeet Singh <gurjeet(at)singh(dot)im>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_regress: lookup shellprog in $PATH
Date: 2022-08-25 14:48:35
Message-ID: 1476139.1661438915@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I mean, I can see you're on the warpath here and I don't care enough
> to fight about it very much, but as a matter of theory, I believe that
> hard-coded pathnames suck. Giving the user a way to survive if /bin/sh
> doesn't exist on their system or isn't the path they want to use seems
> fundamentally sensible to me. Now if system() doesn't do that anyhow,
> well then there is no such mechanism in such cases, and so the benefit
> of providing one in the tiny number of other cases that we have may
> not be there. But if you're trying to convince me that hard-coded
> paths are as a theoretical matter brilliant, I'm not buying it.

If we were executing a program that the user needs to have some control
over, sure, but what we have here is an implementation detail that I
doubt anyone cares about. The fact that we're using a shell at all is
only because nobody has cared to manually implement I/O redirection logic
in these places; otherwise we'd be execl()'ing the server or psql directly.
Maybe the best answer would be to do that, and get out of the business
of knowing where the shell is?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-08-25 14:55:42 Re: shadow variables - pg15 edition
Previous Message Jelte Fennema 2022-08-25 14:47:26 [PATCH] Fix alter subscription concurrency errors