On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
