On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander <magnus@hagander.net> wrote: > Based on that we seem to agree here, should we add this as an open item? > Clearly if we want to change this, we should do so before 10.
This really is a new feature, so as the focus is to stabilize things I think that we should not make the code more complicated because...
The part I'm talking about is the potential adjustment of the patch that's already committed. That's not a new feature, that's exactly the sort of thing we'd want to adjust before we get to release. Because once released we really can't change it.
> I also came up with another case where the current one won't work but it > could be really useful -- if we make a replication connection (with say > pg_receivewal) it would be good to be able to say "i want the master" (or "i > want a standby") the same way. And that will fail today if it needs SHOW to > work, right? > > So having it send that information across in the startup package when > talking to a 10 server, but falling back to using SHOW if talking to an > earlier server, would make a lot of sense I think.
Of this reason, as libpq needs to be compliant with past server versions as well we are never going to save a set of version-dependent if/else code to handle target_session_attrs properly using either a SHOW or a new mechanism.
We'd have to cache the status recived yes. I don't see how that makes it a "set of" if/else code when there is only one if/else now, though? Though admittedly I haven't looked at the actual code for it.
