Re: [WIP] pg_ping utility

Attached is updated patch v4 with the changes Michael pointed out.

On Fri, Nov 16, 2012 at 12:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Phil Sorber <phil(at)omniti(dot)com> writes:
>> On Thu, Nov 15, 2012 at 10:55 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> Hum, it is not really consistent to use a magic number here, particularly in
>>> the case where an additional state would be added in the enum PGPing. So why
>>> not simply return PQPING_NO_ATTEMPT when there are incorrect options or you
>>> show the help and exit? Looks like the best option here.
>
>> Good point. I will make that change as well.
>
> Maybe I missed something here, but I believe it's standard that
> "program --help" should result in exit(0), no matter what the program's
> exitcode conventions are for live-fire exercises. (See
> handle_help_version_opts() in the bin/scripts/ programs, for example.)
> Okay to use NO_ATTEMPT for erroneous arguments, though.

This seems unfortunate. If someone were to put 'pg_ping -V' instead of
'pg_ping -v' into a monitoring script, however misguided, it would
make it appear as though the server were accepting connections even if
it were not. Doesn't really seem to follow our goal of least surprise.

Since this is the standard I have updated the patch to use this
behavior, though I'm not really happy with this. Not sure if I'd
rather break convention, or perhaps leave 0 sacred and add 1 to all
the other return codes to offset them.

Thoughts?

>
> regards, tom lane