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

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