Re: How about an am_superuser GUC parameter (non-settable)?

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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 ;-)

As an example, how many databases have their info spread all over the
place --- I would love if they had it all centralized, as we do with
GUC.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073