> > I think a resonable restriction would be let anyone on the same
> > machine that postmaster is running could issue the protocol.
>
> Grumble. That's both too restrictive and not restrictive enough.
> In an intranet-LAN kind of situation, you'd like to be able to check
> the Postgres status without having to log into the specific machine
> that's running the postmaster; while if the postmaster is running on
> a large multiuser system, the very last thing that you want to do is
> grant access to everyone else on the system.
Ok, let's regard the functionality to report the status of postmaster
and/or backends be separate from pg_ctl.
> > Another idea might be using our host based authentication. What about
> > having a "virtual database" used only for the status request protocol?
>
> That could be workable. But I think I may have a better idea.
>
> This morning after I sent my previous comments, I was thinking that the
> really right way to do it would be to make the status info be a "virtual
> table": you log into Postgres in the normal way, and issue a query
> against some special table name, and if you've got the required access
> rights then you get an answer. The postgres superuser would always get
> an answer, of course, and could grant/deny permissions to other users.
Oracle already has the concept of "virtual table" and I like the idea
too.
> Offhand I don't see any reason to think that making system status look
> like one or more virtual tables would be much harder to implement than
> making it available via special-purpose postmaster protocols. It seems
> worth looking into, anyway.
Tom, I remember you are going to enhance the function manager to allow
functions to return set of rows. If this is possible, it should be
very easy to implement the virtual tables. Is that what is in your
mind?
--
Tatsuo Ishii
