Обсуждение: unixODBC (again)

Hi,

Having seen that the driver I distribute doesn't work against 7.1 Beta
4, and not wanting to continue the split between the two versions,
I have tried to get the driver in the beta working with unixODBC, but
I have come against a couple of problems, one a show stopper.

First let me say that I want to stop the split between the version, If
I can just point people to your distribution, thats fine by me, but it
needs to work :-). I am not trying to get you to standardise on
unixODBC, just to provide the option.

Initially I had to link my system odbc.ini to a user odbc, because the
driver looks in the home account. This would be SO much better if there
was a build option to link with libodbcini.so, not saying it should be
the default, just that the option would be great.

After this, it still didn't find the entries, I fould the problem was
the code couldn't handle spaces in the ini file, so

[dsn]
Servername=fred

works, but

[dsn]
Servername         = fred

doesn't. Not a major point, but again the ini lib would fix this.

Then having sorted this out, I get a core dump, that I have traced to
CC_lookup_pg_version, the code did
   CC_lookup_pg_version(ConnectionClass *self)   {   HSTMT hstmt;   StatementClass *stmt;   RETCODE result;   char
*szVersion= "0.0";   static char *func = "CC_lookup_pg_version";
 

Then later did a
   sprintf( szVersion... );

This seems to be trying to write into, what the compiler is marking as
read only storage. A quick change to
   CC_lookup_pg_version(ConnectionClass *self)   {   HSTMT hstmt;   StatementClass *stmt;   RETCODE result;   char
szVersion[3 ];   static char *func = "CC_lookup_pg_version";
 
       strcpy( szVersion, "0.0" );

Fixes the problem, and it connects. I will continue testing, with some
apps and see how it gets on

--
Nick Gorham
Easysoft Ltd

Nick Gorham writes:

> First let me say that I want to stop the split between the version, If
> I can just point people to your distribution, thats fine by me, but it
> needs to work :-). I am not trying to get you to standardise on
> unixODBC, just to provide the option.

This is nice, but it contradicts your earlier patches, because it would
create a circular dependency:  You need PostgreSQL's ODBC to get unixODBC
set up, but you need [--with-]unixODBC to get PostgreSQL prepared for
unixODBC.  That said if there are improvements in your version, why not
send patches to improve our version, rather than providing patches to link
our version against your version?  That doesn't make sense to me.

I'm not trying to annoy you, I'm just wondering.

> Initially I had to link my system odbc.ini to a user odbc, because the
> driver looks in the home account. This would be SO much better if there
> was a build option to link with libodbcini.so, not saying it should be
> the default, just that the option would be great.

Why not have us include that libodbcini.so in our distribution?
Certainly, no one would get upset if we had better config/ini file
parsing.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Nick Gorham wrote:

>
> Then having sorted this out, I get a core dump, that I have traced to
> CC_lookup_pg_version, the code did
>
>     CC_lookup_pg_version(ConnectionClass *self)
>     {
>     HSTMT hstmt;
>     StatementClass *stmt;
>     RETCODE result;
>     char *szVersion = "0.0";
>     static char *func = "CC_lookup_pg_version";
>
> Then later did a
>
>     sprintf( szVersion... );
>
> This seems to be trying to write into, what the compiler is marking as
> read only storage. A quick change to
>

You are right, it seems a misuse of char *.

>     CC_lookup_pg_version(ConnectionClass *self)
>     {
>     HSTMT hstmt;
>     StatementClass *stmt;
>     RETCODE result;
>     char szVersion[ 3 ];
>     static char *func = "CC_lookup_pg_version";
>
>         strcpy( szVersion, "0.0" );
>

szVersion[3] seems too short.
I would increase the length and commit it soon.

Regards,
Hiroshi Inoue