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 по дате отправления: