Re: [PATCH] pg_regress and non-default unix socket path

On Fri, Apr 12, 2013 at 1:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> The hunk that changes the messages might need some thought so that it
>> doesn't cause a translation regression. But in general I see no
>> reason not to do this before we release beta1. It seems safe enough,
>> and changes that reduce the need for packagers to carry private
>> patches are, I think, generally a good thing.
>
> It looks to me like this is asking for pg_regress to adopt a nonstandard
> interpretation of PGHOST, which doesn't seem like a wise thing at all,
> especially if it's not documented.

I see it the other way around. Most places in PostgreSQL that allow a
hostname also allow a string beginning with a slash to be specified
instead, which then gets interpreted as a socket directory name.
pg_regress does not allow that, and this patch would fix that.

> FWIW, the equivalent thing in the Red Hat/Fedora packages can be seen
> in this patch:
>
> http://pkgs.fedoraproject.org/cgit/postgresql.git/plain/postgresql-var-run-socket.patch
>
> which would not get noticeably shorter if we hacked pg_regress in the
> suggested way. AFAICT, instead of touching pg_regress.c, Red Hat's
> patch would need to do something to the regression Makefiles if we
> wanted to use this implementation. I'm not convinced that'd be better
> at all. TBH, if this is committed, the Red Hat patches will probably
> end up reverting it.

The Red Hat patch is aiming to change the run-time behavior of the
server, which Christoph's patch is not. The net effect would be that
the last two hunks could be ditched in favor of setting
EXTRA_REGRESS_OPTS. I don't imagine that's a big improvement but it
doesn't seem like a step backward, either. I can certainly see the
appeal: IME, it's much nicer to pass in a few extra configuration
options than to have to patch the source.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company