Skip site navigation (1) Skip section navigation (2)

Re: Next development steps?

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Ludek Finstrle" <luf(at)pzkagis(dot)cz>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Next development steps?
Date: 2005-12-16 12:53:59
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4E7EA77@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgsql-odbc
 

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf(at)pzkagis(dot)cz] 
> Sent: 16 December 2005 12:51
> To: Dave Page
> Cc: pgsql-odbc(at)postgresql(dot)org
> Subject: Re: [ODBC] Next development steps?
> 
> > > In my opinion, we should look for the possibility of reworking the
> > > CC_mapping function (which maps PGresult class to QResultClass) to
> > > increase the performance. As Ludek pointed out, we must 
> identify the
> > > code to be cleaned up in different parts of the driver. 
> > 
> > Yes, I'd was thinking about this whilst driving home last night. It
> > seems to me that we should be able to make the PGresult a 
> member of the
> > QResultClass, and then just modify the accessors appropriately. Of
> > course, it's not quite that simple, but I think it's doable.
> 
> Yes, I was thinking about this. And it need some brainstorm ...
> When you use declare/fetch there can be more PGresults or
> what about type conversion (you can take data number of time) 
> and so on.

Yep, both valid points.

> But I'm unable to orient in code becouse a lot of them is unusable
> (I think PQprepare, PQexec with binding params can reduce the 
> code a lot).

OK.

> I call for cleaning the code (even at the expense of some feture lost)
> at first.

I'm not against the idea in principle, but I think we need to discuss
each feature proposed for removal beforehand.

Regards, Dave

Responses

pgsql-odbc by date

Next:From: Ludek FinstrleDate: 2005-12-16 13:15:25
Subject: Re: Next development steps?
Previous:From: Ludek FinstrleDate: 2005-12-16 12:51:08
Subject: Re: Next development steps?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group