Re: Next development steps?
От | Dave Page |
---|---|
Тема | Re: Next development steps? |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E4E7EA77@ratbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Next development steps? (Ludek Finstrle <luf@pzkagis.cz>) |
Ответы |
Re: Next development steps?
|
Список | pgsql-odbc |
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 16 December 2005 12:51 > To: Dave Page > Cc: pgsql-odbc@postgresql.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
В списке pgsql-odbc по дате отправления: