Thread: Re: [COMMITTERS] pgsql: Ah, I finally realize why Magnus wanted to add a --bindir option

Tom Lane wrote:
> Ah, I finally realize why Magnus wanted to add a --bindir option to
> pg_regress: there's no other way to cope with testing a relocated
> installation.  Seems better to call it --psqldir though, since the
> only thing we need to find in that case is psql.

Well, if the ecpg tests materialize, maybe not.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Tom Lane wrote:
>   
>> Ah, I finally realize why Magnus wanted to add a --bindir option to
>> pg_regress: there's no other way to cope with testing a relocated
>> installation.  Seems better to call it --psqldir though, since the
>> only thing we need to find in that case is psql.
>>     
>
> Well, if the ecpg tests materialize, maybe not.
>
>   
Maybe installbindir or some such. As Tom has no doubt observed, this 
change also manages to handle the problem we faced in running 
installcheck under Msys, even when the installation is not relocated 
(buildfarm does not relocate the install - it installs in the configured 
path).

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Peter Eisentraut wrote:
>> Tom Lane wrote:
>>> Ah, I finally realize why Magnus wanted to add a --bindir option to
>>> pg_regress: there's no other way to cope with testing a relocated
>>> installation.  Seems better to call it --psqldir though, since the
>>> only thing we need to find in that case is psql.
>> 
>> Well, if the ecpg tests materialize, maybe not.
>> 
> Maybe installbindir or some such.

The problem with --bindir is that it confuses the purpose with the
build/install-time bindir, which is actually nearly unrelated --- it'll
likely have a similar path tail, but path head could be completely
different.  (Confusing this purpose with bindir was why I failed to grok
the point to start with.)  Call it what you like so long as it ain't
bindir ...
        regards, tom lane