On 2019-Dec-26, Dave Cramer wrote: > On Thu, 26 Dec 2019 at 15:07, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote:
> > There were other comments that I think went largely unaddressed, > > such as the point that the JDBC driver seems to offer a different > > syntax for the configuration, and should we offer a compatibility > > shim of some sort. (Frankly, I don't think we need to stress over > > this too much, but it seems that it wasn't even discussed.) > > We seem to ignore prior work here I agree. It would be wonderful if > there were only one syntax. Is it too late to change the syntax for > this patch as that ship has sailed for JDBC So, starting with pg10 we have target_session_attrs in libpq. These patches just add some more "attrs" that can be requested for a session. Tom's proposal[1] was to rename the conninfo option to match JDBC's targetServerType, adding a compatibility mechanism so that libpq's target_session_attrs continues to work for values "any" and "read-write"; but we already discussed all this with regards to the pgjdbc param names and we still decided not to use them[2] (ending as commit 721f7bd3cbcc). Maybe y'all want to relitigate this for some reason. I can help with getting an implementation finished once y'all are done with the politics. [1] https://postgr.es/m/26251.1547504...@sss.pgh.pa.us [2] https://www.postgresql.org/message-id/CAHg_5grVKbO73CqKNYsCYsX5aJ%3DdeDSAyW44wjmwt1uqngScdQ%40mail.gmail.com (If we do want to match pgJDBC's option name, then I suppose we need to add a synonym mechanism to libpq's option parsing. That doesn't look particularly difficult, and it would probably help clean up the mess that we currently track both the "char *" value of the option as well as a separate enum value for it, in the pgconn struct.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
