On Fri, Apr 14, 2006 at 11:22:23AM -0400, Tom Lane wrote: > Greg's observation is correct, so maybe we are overthinking this > problem. A fair question to ask is whether psqlODBC would consider > going back to a non-hybrid implementation if these features did exist > in libpq.
Well, it is an issue. It's not a specific problem per se that psqlODBC implements the protocol itself. If you remember right back at the beginning of the thread (see subject) there was the issue of users using libpq to connect and then continuing themselves. The issue being that the pointer from PQgetssl() wouldn't work if we had different SSL libraries available. Perhaps a far easier approach would be to indeed just have a hijack interface that provides read/write over whatever protocol libpq negotiated. Then people could write their own protocol parsers to suit their needs while still using libpq for the connection. Have the cake and eat it too? Note, we would have to allow users of libpq to force the version, otherwise libpq would connect using a version the user doesn't understand. > Please mention some specific examples. We need some examples as a > reality check. Well, psqlODBC is the obvious case. Besides that it becomes tricky. I would think that DBI::Pg could benefit, I just don't understand the code well enough to know if it's directly useful. I would expect drivers in particular to benefit and some complex applications, but if you're asking for specific examples, I don't have any... That doesn't change the fact that it's a nice idea, just definite benificiaries are harder to find. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
signature.asc
Description: Digital signature
