Обсуждение: Windows driver sometimes returns connection string with two consecutive semicolons

Поиск
Список
Период
Сортировка

Windows driver sometimes returns connection string with two consecutive semicolons

От
Eric Hill
Дата:

Hey,

 

We cache connection strings in our application so we can know if you already have a connection to a given database.  We ran into this:

 

Windows, Postgres driver version 9.03.03.

 

When you use the ODBC administrator (which we invoke programmatically by passing the empty string as the third argument to SQLDriverConnect()) to connect to Postgres, driver 9.03.03, the connection string you get back (5th argument) has an extra semicolon after “C2=dd_”, to wit:

 

BI=0;C2=dd_;;CX=1c20502bb;

 

However, if you call SQLDriverConnect() passing in that connection string with the extra semicolon as the third argument, a connection is made, and the connection string you get back in the 5th param does *not* have the extra semicolon:

 

BI=0;C2=dd_;CX=1c20502bb;

 

Yes, I can work around this, but why not stop spitting out the extra semicolon in the first case?

 

Thanks!

 

Eric

Re: Windows driver sometimes returns connection string with two consecutive semicolons

От
Heikki Linnakangas
Дата:
On 12/19/2014 11:37 PM, Eric Hill wrote:
> Hey,
>
> We cache connection strings in our application so we can know if you already have a connection to a given database.
Weran into this: 
>
> Windows, Postgres driver version 9.03.03.
>
> When you use the ODBC administrator (which we invoke programmatically by passing the empty string as the third
argumentto SQLDriverConnect()) to connect to Postgres, driver 9.03.03, the connection string you get back (5th
argument)has an extra semicolon after "C2=dd_", to wit: 
>
> BI=0;C2=dd_;;CX=1c20502bb;
>
> However, if you call SQLDriverConnect() passing in that connection string with the extra semicolon as the third
argument,a connection is made, and the connection string you get back in the 5th param does *not* have the extra
semicolon:
>
> BI=0;C2=dd_;CX=1c20502bb;
>
> Yes, I can work around this, but why not stop spitting out the extra semicolon in the first case?

Hmm. This seems to be because there's a trailing semicolon in the
default ExtraSysTablePrefixes attribute, abbtreviated as C2. In other
words, the semicolon is actually part of the "C2=dd_;" attribute.

The trivial fix is to just remove it from ExtraSysTablePrefixes's
default, which makes sense anyway. However, the code that forms the
connection strings is nevertheless broken: if you actually try to put
something with a semicolon in ExtraSysTablePrefixes, like "foo;bar", it
will still do it wrong because it won't escape that.

The code that forms and parses the connection strings is quite a mess.
It needs a rewrite, but for now I have removed the semicolon from the
default, which should fix your immediate problem.

(Does anyone know why "dd_" is the default for extraSysTablePrefixes,
anyway? I don't recognize that prefix. It's been like that forever...)

- Heikki