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