Re: [PATCH] pg_regress and non-default unix socket path - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] pg_regress and non-default unix socket path
Date
Msg-id 20318.1365786018@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] pg_regress and non-default unix socket path  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] pg_regress and non-default unix socket path
Re: [PATCH] pg_regress and non-default unix socket path
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Detach/attach table and index data files from one cluster to another
Next
From: Bruce Momjian
Date:
Subject: Re: Detach/attach table and index data files from one cluster to another