Hi list,
I had a meeting with my client (the one who wanted update support), and
here are the conclusions: It's a long way ahead.
It seems that much more important to the client than being able to
update from the result set is the ability to get most up to date queries
for each fetch. This is a requirement of a "dynaset" view
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Dynaset.asp).
Unfortunately, PostgreSQL does not support cursors that are not of type
"sensitive". Even if it did, it does not support cursors that do not
live inside a transaction. It follows, then, that there is no choice for
an ODBC that wishes to implement a dynaset record but to perform a new
query for each and every fetch operation.
Things are slightly worse, in fact. Because the ordering of the records
in a dynaset are guarenteed to remain the same as when they were first
fetched, some way of determining whether a specific row has changed (or
was deleted) is required. It is at this point that I have to appologize
to Hiroshi if any tone of dismissivness could have been understood from
my previous email regarding his implementation. Making a dynaset work
without using oids is going to be damn tough.
There is one glimmer of hope. The link I gave above claims that we are
allowed to keep, in essence, local copy of the data from the dataset
until a "requery" is done. This means that implementing a dynaset
without huge performance losses is going to be possible (though not easy).
This email is mostly so I can update everyone on the current status. I
have not, yet, formed a concerete plan on what my personal actions on
this matter are going to be. I mostly interested to see whether an
interesting discussion forms as a result of these new discoveries.
Shachar
