Re: How about an am_superuser GUC parameter (non-settable)?

Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Now that CVS tip is rid of the need for libpq to do a "select
> > pg_client_encoding()", I am wondering if we shouldn't make an effort
> > to get rid of psql's "SELECT usesuper FROM pg_catalog.pg_user ..."
> > startup query. All in the name of reduction of connection startup
> > costs, of course.
>
> Well, reducing start-up time for an interactive application from little to
> less seems kind of pointless. (We could avoid that query in
> non-interactive use; I'm not sure if we do already.)
>
> I'm a little uneasy with puttting too much extra burden on the GUC
> mechanism, which is after all a system to configure the server, not to
> retrieve or communicate data. Even the "server_version" thing recently
> added doesn't make me happy. If an application wants to know that, it
> should send a query.

Throwing in my vote, I like the read-only GUC variables, and in fact
like the set-and-can-not-be-changed version if we ever do that too.

I think the GUC centralization is very good. If the GUC system is
strained by this, we can redesign it to handle it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073