BUG #14260: psqlODBC does not support sslXXXXX variables
The following bug has been logged on the website:
Bug reference: 14260
Logged by: Kurt Rayner
Email address: krayner@raynersoft.net
PostgreSQL version: 9.5.3
Operating system: Windows
Description:
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.
It is a relatively minor change to add the certificate/path values to the
options for the ODBC client (admittedly more work to update the dialogs).
I've looked at doing this myself, but would rather see it in the mainline.
Not sure what the process is for acceptance of updates, but if I can
help...
Thanks in advance!
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
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
Attachments:
add_service_dsn_parameter.patchtext/x-patch; charset=US-ASCII; name=add_service_dsn_parameter.patchDownload+19-0
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc