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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: How about an am_superuser GUC parameter (non-settable)?
Дата
Msg-id Pine.LNX.4.44.0304290309060.1928-100000@peter.localdomain
обсуждение исходный текст
Ответ на How about an am_superuser GUC parameter (non-settable)?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: How about an am_superuser GUC parameter (non-settable)?
Re: How about an am_superuser GUC parameter (non-settable)?
Список pgsql-hackers
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.

-- 
Peter Eisentraut   peter_e@gmx.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: prashanth@jibenetworks.com
Дата:
Сообщение: LISTEN/NOTIFY benchmarks?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: How about an am_superuser GUC parameter (non-settable)?