Thread: New ODBC driver

New ODBC driver

From
markw@mohawksoft.com
Date:
What would be the best way to go about re-writing the ODBC driver to use
libpq? (I haven't looked at the code in years, the last time I looked at
it was to find a memory leak.)

Is it possible to do it in stages?

Is the transport sufficiently separated to do a quick change to use libpq
as the transport, and then gradually use more and more?

My only concern would be that a re-write would re-break a lot of
functionality.

Re: New ODBC driver

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of
> markw@mohawksoft.com
> Sent: 01 December 2004 13:50
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] New ODBC driver
>
> What would be the best way to go about re-writing the ODBC
> driver to use libpq? (I haven't looked at the code in years,
> the last time I looked at it was to find a memory leak.)
>
> Is it possible to do it in stages?
>
> Is the transport sufficiently separated to do a quick change
> to use libpq as the transport, and then gradually use more and more?
>
> My only concern would be that a re-write would re-break a lot
> of functionality.

I haven't looked at it in depth, but I think you will essentially just
need to rewrite connection.c as a libpq wrapper.

I don't think it would be realistic to mix the two approaches though -
if only because they couldn't share a single database connection.

Regards, Dave.

Re: New ODBC driver

From
markw@mohawksoft.com
Date:
>
>
>> -----Original Message-----
>> From: pgsql-odbc-owner@postgresql.org
>> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of
>> markw@mohawksoft.com
>> Sent: 01 December 2004 13:50
>> To: pgsql-odbc@postgresql.org
>> Subject: [ODBC] New ODBC driver
>>
>> What would be the best way to go about re-writing the ODBC
>> driver to use libpq? (I haven't looked at the code in years,
>> the last time I looked at it was to find a memory leak.)
>>
>> Is it possible to do it in stages?
>>
>> Is the transport sufficiently separated to do a quick change
>> to use libpq as the transport, and then gradually use more and more?
>>
>> My only concern would be that a re-write would re-break a lot
>> of functionality.
>
> I haven't looked at it in depth, but I think you will essentially just
> need to rewrite connection.c as a libpq wrapper.
>
> I don't think it would be realistic to mix the two approaches though -
> if only because they couldn't share a single database connection.

Why is this an issue? Why not create multiple connections?

>
> Regards, Dave.


Re: New ODBC driver

From
"Dave Page"
Date:

> -----Original Message-----
> From: markw@mohawksoft.com [mailto:markw@mohawksoft.com]
> Sent: 01 December 2004 15:02
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] New ODBC driver
>
> > I don't think it would be realistic to mix the two
> approaches though -
> > if only because they couldn't share a single database connection.
>
> Why is this an issue? Why not create multiple connections?

Efficiency for a start - but what would you use each for? Any
application developer is going to expect everything to use the same
connection - how do you direct a 'SET' statement? What about transaction
isolation?

Regards, Dave.

Re: New ODBC driver

From
markw@mohawksoft.com
Date:
>
>
>> -----Original Message-----
>> From: markw@mohawksoft.com [mailto:markw@mohawksoft.com]
>> Sent: 01 December 2004 15:02
>> To: Dave Page
>> Cc: pgsql-odbc@postgresql.org
>> Subject: Re: [ODBC] New ODBC driver
>>
>> > I don't think it would be realistic to mix the two
>> approaches though -
>> > if only because they couldn't share a single database connection.
>>
>> Why is this an issue? Why not create multiple connections?
>
> Efficiency for a start - but what would you use each for? Any
> application developer is going to expect everything to use the same
> connection - how do you direct a 'SET' statement? What about transaction
> isolation?
>
> Regards, Dave.

OK, I'm going to take a look at it.

I have a stupid question, where is the location of the ODBC source? Is it
part of PostgreSQL?


>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>


Re: New ODBC driver

From
"Dave Page"
Date:

> -----Original Message-----
> From: markw@mohawksoft.com [mailto:markw@mohawksoft.com]
> Sent: 01 December 2004 16:21
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] New ODBC driver
>
> >
> >
> >> -----Original Message-----
> >> From: markw@mohawksoft.com [mailto:markw@mohawksoft.com]
> >> Sent: 01 December 2004 15:02
> >> To: Dave Page
> >> Cc: pgsql-odbc@postgresql.org
> >> Subject: Re: [ODBC] New ODBC driver
> >>
> >> > I don't think it would be realistic to mix the two
> >> approaches though -
> >> > if only because they couldn't share a single database connection.
> >>
> >> Why is this an issue? Why not create multiple connections?
> >
> > Efficiency for a start - but what would you use each for? Any
> > application developer is going to expect everything to use the same
> > connection - how do you direct a 'SET' statement? What about
> > transaction isolation?
> >
> > Regards, Dave.
>
> OK, I'm going to take a look at it.
>
> I have a stupid question, where is the location of the ODBC
> source? Is it part of PostgreSQL?
>

http://gborg.postgresql.org/project/psqlodbc, in the CVS section.

Regards, Dave,