[ODBC] Re: Connection failure with invalid connection option "gsslib" for09.06.0410

Hi Michael,

On 2017/08/21 10:01, Michael Paquier wrote:
> Hi all,
>
> When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I
> lagged behind one release!), I have noticed a failure when connecting
> to a Postgres instance on Windows:
> cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm
> --user test_odbc --pwd passw0rd --port 5444
> stdout=Connecting odbc :
> DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd};
>
> stderr=Traceback (most recent call last):
>    File "check_odbc.py", line 111, in main
>      check_odbc_connection(conn_str)
>    File "check_odbc.py", line 15, in check_odbc_connection
>      cnxn = pyodbc.connect(conn_str)
> Error: ('08001', '[08001] invalid connection option "gsslib"\n (101)
> (SQLDriverConnect)')

Unfortunately I can't reproduce it here with dns-less connections.
What is in uninst_std_noimpact_srm?

regards,
Hiroshi Inoue

>
> check_odbc.py is a simple wrapper on top of pyodbc that attempts a
> connection to Postgres on Windows, making sure that the DNS defined is
> working correctly. There is nothing fancy in it.
>
> The difference between a failure and a success is only the update of
> the ODBC driver, so I'd like to think that it is its fault here ;)
>
> Looking at the code, I think that this diff in dlg_specific.c, coming
> from commit 3bad6c8e is at fault:
> @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char
> *attribute, const char *value)
>   }
> [...]
> -void
> -getDSNdefaults(ConnInfo *ci)
> +static void
> +getCiDefaults(ConnInfo *ci)
> [...]
> -   if (ci->gssauth_use_gssapi < 0)
> -       ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
> [...]
> +   ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>
> This is a problem, because Postgres' libpq may not be compiled with
> GSS support, which is the case of my builds, and the existence of the
> connection parameter gsslib depends on if Postgres is compiled with
> GSS or not. I think also that this is the only problem, the other
> libpq parameter whose existence is defined based on compilation is
> krbsrvname, and odbc does not handle it. I have only seen this problem
> on Windows, because my Linux builds have GSS support, but I have no
> doubt that the problem could be seen there as well.
>
> Inoue-san, unfortunately I think that your commit is a fault here.
> Thanks,