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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073