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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема How about an am_superuser GUC parameter (non-settable)?
Дата
Msg-id 3177.1051310101@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: How about an am_superuser GUC parameter (non-settable)?
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_namespace -> pg_schema?
Следующее
От: Joe Conway
Дата:
Сообщение: conflicting libraries at runtime