On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander <mag...@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. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>