-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> I do find it a bit hard to imagine that any program capable of shelling
> out to call pg_controldata and doing something with the output would hit
> a major hurdle parsing the format that's already there.
+1
> 1) How do you handle the situation where the pg_controldata is invalid?
Throw an error
> 2) While it's easy to say "I only want one or two of these values" and
> expose a whole set of UDFs to grab them individually (perhaps wrapping
> into a system view via that popular approach), I am concerned that
> people are going to call any single-value versions provided one at a
> time and get an inconsistent set.
I'm not too concerned about this. This will be a fairly advanced interface,
and a warning in the docs should suffice. I think a good interface will
help however. I'd lean towards something like pg_settings.
What I *would* like to see is two tweaks to the output of pg_controldata.
First, having the "time of latest checkpoint" appear as an epoch (rather than
or in addition to a localized time string) would help quite a bit. Second, it
can be hard to build regex solutions when you don't know whan language your
end user will be using. Not sure of the best solution for that one off the top of
my head, but there are some workarounds. For example, check_postgres.pl stores
all the languages translations of "Time of latest checkoint" to help it find that
information, but I'd sure like a more elegant solution. (One could count lines,
but that's presumes the order and number of items will never change).
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201003050945
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkuRGYMACgkQvJuQZxSWSsiDvgCgxgFtcy99ehUGt7i7gCp8zRTY
044An1JEEwki9KLZu5BhKXCUNGqfyXDf
=ruYL
-----END PGP SIGNATURE-----
