Date: Thu, 26 Dec 2019 18:58:37 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Dave Cramer <pg@fastcrypt.com>
Cc: Greg Nancarrow <gregn4422@gmail.com>,
	"Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
	Haribabu Kommi <kommi.haribabu@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Laurenz Albe <laurenz.albe@cybertec.at>,
	Tom Lane <tgl@sss.pgh.pa.us>, Jing Wang <jingwangian@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Elvis Pranskevichus <elprans@gmail.com>
Subject: Re: Libpq support to connect to standby server as priority
Message-ID: <20191226215837.GA18530@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CADK3HHLo-jTh4S1PYd7Qx5t8hscH-6emBy9fWFv1dUwhPzyTzA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2019-Dec-26, Dave Cramer wrote:

> On Thu, 26 Dec 2019 at 15:07, Alvaro Herrera <alvherre@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.1547504236@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