How about an am_superuser GUC parameter (non-settable)? - Mailing list pgsql-hackers

From Tom Lane
Subject How about an am_superuser GUC parameter (non-settable)?
Date
Msg-id 3177.1051310101@sss.pgh.pa.us
Whole thread Raw
Responses Re: How about an am_superuser GUC parameter (non-settable)?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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.

It'd be possible to do this using the just-implemented ParameterStatus
message, if we defined a non-user-settable boolean GUC parameter named,
say, "am_superuser", which'd be updated automatically at startup and
by any SET SESSION AUTHORIZATION command.  (I'm envisioning that it
would track your effective privileges rather than just being static.)
This would let psql maintain its prompt information at nearly no cost
--- an extra twenty bytes or so in a message that the backend will be
sending anyway.  And the prompt could do the right thing when you setuid
to a non-superuser, which right now it doesn't.

Is this overkill?  Too limited?  Are there any frontends besides psql
that would find something like this useful?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_namespace -> pg_schema?
Next
From: Joe Conway
Date:
Subject: conflicting libraries at runtime