This article would be way more useful if it named the offending drivers and linked to relevant github issues. As is this is just a set of useless curiosities.<p>I came in wanting to check if any of the drivers I use were affected by any of the bugs they found. No idea!
SQL Database drivers have so much in common, but each represent schema and data table(s) differently on the wire. Some handle cancellation within the protocol, others require a work around (like another DB connection that issues a KILL command). TDS (Microsoft Server) is actually one of the better protocols and better documented protocols (due in large part to historical court orders) out there.<p>My takeaway is that compact schema streaming data is not a well developed field. I think we can do better. Not only that, but developing both such a schema, protocol, and associated tooling is key to significantly better data-centric applications from end to end, not just the database.
I've had such problems with the official AWS redshift JDBC driver -- Mostly around memory usage compared to the PG8.4 driver that also works. But also,<p>- Much slower to cancel queries<p>- Still reading and buffering most of the result after
canceling.<p>- Weird escaping issues<p>Glad to be done with that.
Hello, maintainer of the pg8000 driver for PostgreSQL here. I'm keen to know of any problems you had if you used pg8000. Thanks! <a href="https://github.com/tlocke/pg8000" rel="nofollow">https://github.com/tlocke/pg8000</a>
I remember dealing with DataDirect on Linux more than 10 years ago. I don't recall the specifics, but under certain error conditions, either the ODBC driver we were using or the driver manager would simply do `exit(0)` with no errors logged anywhere. That was a "fun" one to solve...
Speaking as a professional data yeeter who has been bit by weird driver issues in the past, I’ll go against the grain to say that I found this really helpful as a checklist to pattern match against when troubleshooting, even without calling out specific drivers. Thanks for sharing!
The world would be a better place if database drivers were completely abandoned as a way for clients to connect to databases. A standard API, implemented by multiple vendors, is a vastly preferable solution. Arrow Flight is an example of this.<p><a href="https://arrow.apache.org/blog/2019/10/13/introducing-arrow-flight/" rel="nofollow">https://arrow.apache.org/blog/2019/10/13/introducing-arrow-f...</a>
I used to work with Sybase, and its JDBC driver was pure madness. There were times where the same query on same data would return different results. Never figured out why. We ended use its ODBC driver for reporting instead.
I remember something about mysql not treating localhost as local, but 127.0.0.1 would. This led to very different performance. (Long ago, not sure about details)<p>Also surprised by libraries not using more efficient protocols although they were defined.<p>Compression also doesn’t seem to be a thing.
Found out recently that utilizing Snowflake from Spark that you still cant represent higher than int32 normally, driver doesn't support it.<p>I think its in the works but it makes me laugh that the big data folks never really cared about a number bigger than 2.4b or so.
Why isn't there an HTTP protocol like "Query:" or "SQL:" such that drivers and ODBC/JDBC are not required to talk to a typical database? In other words, a database web service standard. Here's a sample of what the XML could look like:<p><a href="https://www.reddit.com/r/Database/comments/p21u5d/standard_query_web_service_draft_proposal/" rel="nofollow">https://www.reddit.com/r/Database/comments/p21u5d/standard_q...</a>
I will presume that at least half of these are issues with the Snowflake connectors until told otherwise.. those guys have a great core product, but the connectors are pretty dodgy in many cases I've seen.<p>Telling as well that DuckDB fixed your issue in a couple of days.. had snowflake support even demonstrated technical understanding of your request in that time? I guess it doesn't really matter if it takes them six months or more to fix the connector bugs anyway.