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 <peter_e@gmx.net>) |
Ответы |
Re: How about an am_superuser GUC parameter (non-settable)?
Re: How about an am_superuser GUC parameter (non-settable)? |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> 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 по дате отправления: