Ron Teitelbaum wrote:
> I had to make some changes to get the postgres2 client running on squeak
> 3.9.  I posted a bug with the changes in mantis and sourceforge.  The
> problem is I didn't copy the original versions into my repository and now
> I'm on my own version 4.  I really need to go back and figure it out and
> load the new squeak port to try it out.

The SqueakSource repository for PostgresV2 is world writable,
so anyone should be able upload new/fixed versions.

> I'm guessing my version doesn't report the errors at all.  Sorry.  Please
> keep us informed if you figure out the problem or if you have a reproducible
> example, I'd be happy to try it out and help you debug it.

A test case would certainly be useful. I'm not currently a
user of Glorp, so I can't speculate on its error handling.

Have you tried submitting your logged SQL statements through
the PostgresV2 client? The TestPGConnection class should have
code you can adapt to send a sequence of SQL.

One thing to note is that the frontend/backend communication
is event-driven. It wouldn't surprise me if an error message were
to take a long time to arrive at the client, given the scenario
that was outlined (db with some constraints, begin, lots of updates,
and then commit).

IIRC, the backend should not respond with a packet that indicates
it's ready to accept a new SQL stmt, following the commit, until
it is ready. But, there's no guarantee that an error message
from the previous statement will be returned, before the ready
for next query packet is sent. The PGConnection public api is
a synchronous overlay on top of the underlying event-driven
state-machine. I seem to recall that in some cases error message
packets get written to the Transcript, but I'd have to check the
code to refresh my memory.

HTH.
-- 
Yanni Chiu