On Mon, Oct 15, 2012 at 9:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Phil Sorber <phil(at)omniti(dot)com> writes:
>> On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Yeah, I know a whole new executable is kind of a pain, and the amount of
>>> infrastructure and added maintenance seems a bit high compared to what
>>> this does. But a lot of the programs in src/bin/scripts are not much
>>> bigger. (In fact that might be the best place for this.)
>
>> I considered src/bin/scripts but all those are for maintenance tasks
>> on the DB. createdb/vacuumdb/reindexdb etc. It doesn't need any of the
>> bits in common.h/common.c, nor does it need some of the includes that
>> the build process has.
>
> Well, we classify all those programs as client-side tools in the
> documentation, so I don't see that pg_ping doesn't belong there.
>
> The alternative is to give it its very own subdirectory under src/bin/;
> which increases the infrastructure burden *significantly* (eg, now it
> needs its own NLS message catalog) for not a lot of value IMO.
>
>> I would also like it to have a regression test
>> which none of those seem to have.
>
> [ shrug... ] There is nothing in the current regression infrastructure
> that would work for this, so that desire is pie-in-the-sky regardless of
> where you put it in the source tree. Also, PQping itself is exercised
> in every buildfarm run as part of "pg_ctl start", so I don't feel a real
> strong need to test pg_ping separately.
>
> regards, tom lane
Here is the new patch. I renamed the utility from pg_ping to pingdb to
go along with the naming convention of src/bin/scripts. Updated docs
and made some other minor improvements.