On Thu, Jul 21, 2016 at 8:52 AM, Lindsay Stevens
<lindsay.stevens.au@gmail.com> wrote:
> I long while back I had a similar issue and drafted a patch (working code /
> build but no test) to add some libpq parameter support. It was for
> pg_service, which can point to a connection config file and leverages
> libpq's ability to read that for any / all possible parameters.
Do you have any reference to pg_service? I am not very familiar with
that. Still it sounds weird to
> At the time, Heikki was doing the only commits and suggested a non file
> based approach where we pass in to libpq any provided parameters not
> currently explicitly handled. This has the advantage over pg_service of not
> having to supply a service config file with the application. I wasn't sure
> how to do that though (rudimentary C skills...) and had a workaround for the
> motivating problem so I left it alone.
So that's a deal to avoid bloating up the number of parameters present
directly in
> What would be the current preferred approach? E.g. (or some combination of)
>
> 1. write boilerplate-ish code to explicitly handle all current libpq
> parameters, or
That's rally bloaty. Many parameters are not supported in the driver now.
> 2. write the above pass-all-in feature, or
OK, I think I see. I am not sure what Heikki had in mind here, but a
pure guess is that this is a method using PQconndefaults. Now I am not
sure about something... How do we pass new parameters and custom
values?
> 3. use pg_service.
OK, I see. This looks quite promising as libpq already has logic to
handle the service configuration file.
--
Michael
