Thread: Re: [BUGS] BUG #14260: psqlODBC does not support sslXXXXX variables

On Tue, Jul 19, 2016 at 11:00 PM,  <krayner@raynersoft.net> wrote:
> Bug reference:      14260
> Logged by:          Kurt Rayner
> Email address:      krayner@raynersoft.net
> PostgreSQL version: 9.5.3
> Operating system:   Windows
> Description:

Postgres ODBC and Postgres server code are two different things. Note
that the last versions of the Postgres ODBC driver have a hard
dependency with libpq, but I guess you know that. By the way,
pgsql-bugs applies to bugs of Postgres code code, as this is an
ODBC-related problem I am moving this thread to pgsql-odbc.

> pSQLODBC does not accept the sslXXX options for OpenSSL that other database
> clients do):
> sslcert
> sslkey
> sslrootcert
> sslcrl
> sslcipher (doesn't appear to be supported by libpq).
>
> This is more of a deficiency, but in a multi-threaded client where each
> connection can have different values putenv() really doesn't cut it.

Agreed. hose are definitely missing from ConnInfo and should be
enforced in LIBPQ_connect@connection.c when passing the list of libpq
parameters to PQconnectDBParams. I have not looked at the code in
details, but this also needs some work in the files dlg_*.c to be able
to build correctly, and this needs dedicated parameters for the .ini
configuration file.

> Not sure what the process is for acceptance of updates, but if I can
> help...

Patches are welcome! Development of ODBC is an on-going process.
--
Michael

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.

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.

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
2. write the above pass-all-in feature, or
3. use pg_service.

I've attached my patch for 3, and could work on 1, but I'd need some pointers (ha) on doing 2.

Best regards,
Lindsay

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