Re: How about an am_superuser GUC parameter (non-settable)? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: How about an am_superuser GUC parameter (non-settable)?
Date
Msg-id 11465.1051581966@sss.pgh.pa.us
Whole thread Raw
In response to Re: How about an am_superuser GUC parameter (non-settable)?  (Peter Eisentraut <peter_e@gmx.net>)
Responses 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>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: How about an am_superuser GUC parameter (non-settable)?
Next
From: Tom Lane
Date:
Subject: Re: LISTEN/NOTIFY benchmarks?