Re: How about an am_superuser GUC parameter (non-settable)?
От
Tom Lane
Тема
Re: How about an am_superuser GUC parameter (non-settable)?
Дата
Msg-id
11465.1051581966@sss.pgh.pa.us
Ответ на
Re: How about an am_superuser GUC parameter (non-settable)? (Peter Eisentraut)
Список
Дерево обсуждения
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)? Peter Eisentraut <peter_e@gmx.net>
Re: 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)? Bruce Momjian <pgman@candle.pha.pa.us>
Re: How about an am_superuser GUC parameter (non-settable)? Bruce Momjian <pgman@candle.pha.pa.us>
Re: How about an am_superuser GUC parameter (non-settable)? Bruce Momjian <pgman@candle.pha.pa.us>
Peter Eisentraut writes: > 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. Well, I think there is a very demonstrable reason to send the server version as part of the startup protocol: "send a query" isn't a trustworthy way for an application to find that out, given the rate at which we are changing the server. For example, the fully correct way to do that in 7.3 is "select pg_catalog.version()", but this syntax doesn't work at all in pre-7.3 servers. And that doesn't even consider the autocommit issue... If GUC didn't exist then a green-field design for sending the server version during startup would doubtless have looked different. But we have the mechanism, it performs excellently, and extending it in this particular direction seems like a very reasonable design choice to me. You know not how well you wrought ;-) regards, tom lane
В списке pgsql-hackers по дате отправления
От: Bruce Momjian
Дата: