Обсуждение: 9.0 Driver

Is there a 9.0 Driver?

Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422

Looks like they're working on a 9.0 version in the HEAD code tree at the CVS repository.

    http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/docs/

Maybe you could try building it?

    http://psqlodbc.projects.postgresql.org/win32-compilation.html
    http://psqlodbc.projects.postgresql.org/unix-compilation.html

Regards,

Scott Langley
slangley@scharp.org

psqlODBC release notes

---

psqlODBC 09.00.0100 Prep Release

Changes:
1.) Allow password which contains special characters like {,},=,;.
2.) Add a new data source option which makes it possible to use Kerberos for Windows library to reply to GSSAPI authentication request.
3.) Native support for SSPI Kerberos or Negaotiate service. It may be useful for the 64-bit drivers.
4.) Fix an oversight of Memory overflow handling.
5.) Removed "#define SQL_WCHART_CONVERT" which causes a trouble on some platforms.
6.) Removed the use of misused strcat_s together with snprintf_s (bug report from Jap-Peter Seifert) and use strlcat instead of strncat.
7.) Fix a bug about pre-execute behavior in case of protocol v2 or earlier.
8.) Use poll() instead of select() when it's available.
9.) Take comments or line comments in a query into account.
10.) Fix a crash bug on authentication failures.
11.) Take --without-iodbc(unixODBC) configure option into account.
12.) Apply the patch by Peter Crabtree which fixes a crash bug.
13.) Improve the handling of bools_as_char case.
14.) Fix a bug when creating a connection string.



Jason Tesser wrote:

Is there a 9.0 Driver?

Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422

On Fri, 6 Aug 2010, Scott Langley wrote:

> Looks like they're working on a 9.0 version in the HEAD code tree at the CVS
> repository.
>
>     http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/docs/

That's the ODBC driver.

I aim to produce a 9.0 driver beta release to go with RC1 of the server.

Kris Jurka

Great thanx Kris that is what I was wondering.

Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422

There is, I believe, a problem with the JDBC driver in that it gives very poor performance doing a refreshRow. The
problemis that the driver queries the server for every column in the resultset. 

I implemented a quick and dirty fix by modifying the driver to (on demand) use the labels returned in the resultset.

This solution of course will fail if the original query used an alias for a column. Other than that, it seems to be a
goodsolution. 

Apparently I am the only one who uses refreshrow, because I reported the fact that it was slow in January (and there
wasa little discussion) but when in April I reported my crude solution there was no discussion. 

John

On Sun, 8 Aug 2010, John T. Dow wrote:

> There is, I believe, a problem with the JDBC driver in that it gives
> very poor performance doing a refreshRow. The problem is that the driver
> queries the server for every column in the resultset.
>
> I implemented a quick and dirty fix by modifying the driver to (on
> demand) use the labels returned in the resultset.
>
> This solution of course will fail if the original query used an alias
> for a column. Other than that, it seems to be a good solution.
>
> Apparently I am the only one who uses refreshrow, because I reported the
> fact that it was slow in January (and there was a little discussion) but
> when in April I reported my crude solution there was no discussion.

I think it's a combination of factors, few people use refreshRow and fewer
people use it on results with hundreds of columns.  Yes, it is slow, but
it isn't abysmal and it's only slow for the first refreshRow execution
on the ResultSet, so subsequent refreshes are fast.  As you've stated, the
solution you've implemented is inadequate for the general case, so I'm not
sure what further discussion there should be about it.  Is there something
in particular you'd like feedback on?

So yes, it's a known issue, but not a high priority one.

Kris Jurka

On Tue, 10 Aug 2010 13:56:27 -0400 (EDT), Kris Jurka wrote:

>
>
>On Sun, 8 Aug 2010, John T. Dow wrote:
>
>> There is, I believe, a problem with the JDBC driver in that it gives
>> very poor performance doing a refreshRow. The problem is that the driver
>> queries the server for every column in the resultset.
>>
>> I implemented a quick and dirty fix by modifying the driver to (on
>> demand) use the labels returned in the resultset.
>>
>> This solution of course will fail if the original query used an alias
>> for a column. Other than that, it seems to be a good solution.
>>
>> Apparently I am the only one who uses refreshrow, because I reported the
>> fact that it was slow in January (and there was a little discussion) but
>> when in April I reported my crude solution there was no discussion.
>
>I think it's a combination of factors, few people use refreshRow and fewer
>people use it on results with hundreds of columns.  Yes, it is slow, but
>it isn't abysmal and it's only slow for the first refreshRow execution
>on the ResultSet, so subsequent refreshes are fast.  As you've stated, the
>solution you've implemented is inadequate for the general case, so I'm not
>sure what further discussion there should be about it.  Is there something
>in particular you'd like feedback on?
>
>So yes, it's a known issue, but not a high priority one.
>
>Kris Jurka
>
>


I see that once a field gets its name, it remembers it. You're right about that.

I am not looking for any feedback on my quick and dirty solution, although it seemed that if others were experiencing
theproblem they might be interested to know that there is a solution of sorts at hand. Didn't happen. I must be alone. 

All I know is a client complained that it was taking 20 seconds for their remote warehouse staff to update the
database.Made me look bad after I'd sold them on PG. (I timed it - it wasn't always that bad, but after I implemented
myfix and tested it several times, it dropped from 15 seconds to 3 seconds to do a refreshRow.) 

I should think the code could get all the attname, attnum pairs for a given attrelid with one round trip and cache the
results.Is there some good reason not to do so? 

John