> Oops, it's my mistake. It may be better to rewrite the code completely
> using libpq APIs instead of ODBC APIs.
I don't know if that'll work.
Nothing requires the transaction co-ordinator to be local to the
database. The ODBC app using the local MSDTC might be talking to an
Amazon RDS instance for all we know or care. All the local transaction
co-ordinator needs is to be able to talk to the database.
That becomes a problem if the user is using a pre-defined System DSN,
User DSN or File DSN rather than a string DSN like in the test case I've
been working with. At least with a string DSN we can parse out the
relevant details and make a libpq connection. With indirect DSNs we
can't do that (AFAIK), we'd need a way to ask ODBC / psqlODBC what the
connection parameters were in a way we could pass to libpq.
OTOH, the same issue seems to rule out just rewriting the driver name in
the connection string. We can't do that if it's indirect via a file,
user or system DSN, AFAIK.
I'll need to read a bunch of documentation and do some more testing
before I'm confident of any of that, though.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
