Thread: How about an am_superuser GUC parameter (non-settable)?
Now that CVS tip is rid of the need for libpq to do a "select
pg_client_encoding()", I am wondering if we shouldn't make an effort
to get rid of psql's "SELECT usesuper FROM pg_catalog.pg_user ..."
startup query. All in the name of reduction of connection startup
costs, of course.
It'd be possible to do this using the just-implemented ParameterStatus
message, if we defined a non-user-settable boolean GUC parameter named,
say, "am_superuser", which'd be updated automatically at startup and
by any SET SESSION AUTHORIZATION command. (I'm envisioning that it
would track your effective privileges rather than just being static.)
This would let psql maintain its prompt information at nearly no cost
--- an extra twenty bytes or so in a message that the backend will be
sending anyway. And the prompt could do the right thing when you setuid
to a non-superuser, which right now it doesn't.
Is this overkill? Too limited? Are there any frontends besides psql
that would find something like this useful?
regards, tom lane
Tom Lane writes: > Now that CVS tip is rid of the need for libpq to do a "select > pg_client_encoding()", I am wondering if we shouldn't make an effort > to get rid of psql's "SELECT usesuper FROM pg_catalog.pg_user ..." > startup query. All in the name of reduction of connection startup > costs, of course. Well, reducing start-up time for an interactive application from little to less seems kind of pointless. (We could avoid that query in non-interactive use; I'm not sure if we do already.) 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. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Tom Lane writes: > > > Now that CVS tip is rid of the need for libpq to do a "select > > pg_client_encoding()", I am wondering if we shouldn't make an effort > > to get rid of psql's "SELECT usesuper FROM pg_catalog.pg_user ..." > > startup query. All in the name of reduction of connection startup > > costs, of course. > > Well, reducing start-up time for an interactive application from little to > less seems kind of pointless. (We could avoid that query in > non-interactive use; I'm not sure if we do already.) > > 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. Throwing in my vote, I like the read-only GUC variables, and in fact like the set-and-can-not-be-changed version if we ever do that too. I think the GUC centralization is very good. If the GUC system is strained by this, we can redesign it to handle it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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
Tom Lane wrote: > 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 ;-) 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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > 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 ;-) I don't see this implemented yet. I know Peter didn't like it, but I saw no other objections. Is it a TODO item? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073