On Tue, Jan 9, 2018 at 3:36 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > I agree a backend status message is the right way to do this. > > We could perhaps report transaction_read_only, if we don't want to add a > new one.
That's not really the same thing, though. I think that we really need to think about allowing clients to tell the server which GUCs they'd like reported, instead of having a single list to which everyone is bound. A new protocol option using the facilities added in commit ae65f6066dc3d19a55f4fdcd3b30003c5ad8dbed, like _pq_.report=work_mem might be one way, though that doesn't give a psql session the option of changing its mind in mid-session. If we wanted to allow that, we could teach the server to understand a new message to change protocol options and let psql send it to sufficiently-new servers. Way back in the day, we used to reject every proposed new EXPLAIN option because we didn't want to add keywords for all of those things; nowadays, we reject every new GUC_REPORT GUC because it adds overhead for everyone. The solution there was to change the rules of the game so that EXPLAIN options didn't have to be keywords, and I think the solution here is to change the game so it doesn't add overhead for everyone. We might also want to consider de-GUC-reportify some things that are GUC_REPORT now. DateStyle, IntervalStyle, TimeZone, application_name aren't used by anything in core. Apparently we have application_name as GUC_REPORT because pgbouncer wants it (59ed94ad0c9f74a3f057f359316c845cedc4461e, 2009), TimeZone because JDBC wants it (b5ae0d69da8f83e400921fcdd171e5bdadb45db3, 2004), IntervalStyle I suppose because it was copied from DateStyle (df7641e25ab4da6f3a48222cbda0e121ccb32ad5, 2008) and DateStyle from the very beginning for unspecified reasons (b700a672feadbb6f122b7c7249967fb0f58dda2b, 2003). If clients can request the GUCs they care about, it becomes much less important for the default list to be comprehensive. As a side benefit, then Craig and Tom can stop arguing about whether server_version_num should be GUC_REPORT. Under this proposal, you can have it whichever way you like. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
