On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> Why not add a pg_ctl subcommand for that? For me that sounds like a good place
>> for it...
>
> I think that's a bad fit, because every other pg_ctl subcommand requires
> access to the data directory. It would be very confusing if this one
> subcommand worked remotely when the others didn't.
>
> There was also some discussion of wedging it into psql, which would at
> least have the advantage that it'd typically be installed on the right
> side of the client/server divide. But I still think "wedging into" is
> the appropriate verb there: psql is a tool for making a connection and
> executing some SQL commands, and "ping" is not that.
>
> 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.)
>
> regards, tom lane
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. I would also like it to have a regression test
which none of those seem to have. Seems like it would be a bit of a
wedge there as well, but if we did, maybe we call it pingdb instead?
If there is consensus that we want it to live there, I can write a
patch for that as well. Though just to be clear my preference at this
point is still for a standalone binary.
