On Sun, Sep 6, 2015 at 3:34 PM, Joe Conway <m...@joeconway.com> wrote: > On 09/02/2015 02:54 PM, Alvaro Herrera wrote: >> Josh Berkus wrote: >>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote: >>>> I think trying to duplicate the exact strings isn't too nice an >>>> interface. >>> >>> Well, for pg_controldata, no, but what else would you do for pg_config? >> >> I was primarily looking at pg_controldata, so we agree there. >> >> As for pg_config, I'm confused about its usefulness -- which of these >> lines are useful in the SQL interface? Anyway, I don't see anything >> better than a couple of text columns for this case. > > There are production environments where even the superuser has no > direct, local, command line access on production database servers (short > of intentional hacking, which would be frowned upon at best), and the > only interface for getting information from postgres is via a database > connection. So to the extent pg_config and pg_controldata command line > binaries are useful, so is the ability to get the same output via SQL.
I don't buy that argument as far as pg_config is concerned. That's mostly providing local pathnames. If you don't have command-line access to the box where the server is running, you not only can't use that information, but you probably aren't really entitled to it. I see exposing the pg_controldata information as reasonable because that's actually facts about the database cluster, rather than the system on which it is running. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
