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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: How about an am_superuser GUC parameter (non-settable)?
Date: 2003-04-29 02:06:06
Message-ID: 11465.1051581966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ;-)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-04-29 02:19:16 Re: LISTEN/NOTIFY benchmarks?
Previous Message Bruce Momjian 2003-04-29 01:40:45 Re: How about an am_superuser GUC parameter (non-settable)?