Andrew Dunstan wrote:
>
> Well, contributions come in many forms, not just patches. Note too
> that almost all the requested features had nothing to do with core
> postgres, which is what this list is about
Well, as a driver developer I can tell you that the core teams attitude
toward driver driven requests can get frustrating. It usually boils down
to "that's the way it is, deal with it", often without even giving me
the option to intelligently deal with it.
I haven't been very active lately (and OLE DB has suffered as a result,
to be sure), but there were some areas where it was not a matter of
doing the coding. I offered initial code, and was willing to work on it
to make sure it matures into a full patch, backwards compatible and
without any significant performance costs. It was more a matter of "it
doesn't affect Postgresql's core, so it's not important" attitude that
really makes life difficult for a driver developer.
Drivers are important, guys. There aren't enough people willing to dive
into the mess that is OLE DB/.Net etc as is. Let's try to at least
acknowledge that there is a need.
Shachar
p.s.
If I may remark on someone else's turf. ODBC has a thing called "dynamic
view". As far as database design, it's a horrid mess, but it's in the
specs, and it requires tracking what happens to specific rows of a query
after a transaction has finished. The last time I checked (which was
when Hiroshi was still the ODBC maintainer), ODBC was emulating it
series of queries on the tid and oid of the rows. It was semantically
correct, but required round trip for each row query, as well as not
being able to work on rows returned from views and other non-table sources.
I don't know who took over ODBC, and whether dynamic views were restored
(the driver turned read-only for a while) or how, but if they come
asking for some crazy scheme that includes tracking what happens to the
rows of a query after the transaction in which it happened is over,
please listen to them. It's not their crazyness, it's ODBC's.
