On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer <davecramer@postgres.rocks> wrote: > Well now you are asking the driver to re-interpret the results in a different way than the server which is not what we tend to do. > > The server throws an error we throw an error. We really aren't in the business of re-interpreting the servers responses.
I don't really see a reason why the driver has to throw an exception if and only if there is an ERROR on the PostgreSQL side. But even if you want to make that rule for some reason, it doesn't preclude correct behavior here. All you really need is to have con.commit() return some indication of what the command tag was, just as, say, psql would do. If the server provides you with status information and you throw it out instead of passing it along to the application, that's not ideal.
Well con.commit() returns void :(
Another thing that kinda puzzles me about this situation is that, as far as I know, the only time COMMIT returns ROLLBACK is if the transaction has already previously reported an ERROR. But if an ERROR gets turned into an exception, then, in the code snippet previously provided, we'd never reach con.commit() in the first place.
The OP is building a framework where it's possible for the exception to be swallowed by the consumer of the framework.
I'm not trying to deny that you might find some other server behavior more convenient. You might. And, to Vik's original point, it might be more compliant with the spec, too. But since changing that would have a pretty big blast radius at this stage, I think it's worth trying to make things work as well as they can with the server behavior that we already have. And I don't really see anything preventing the driver from doing that technically. I don't understand the idea that the driver is somehow not allowed to notice the command tag.
We have the same blast radius.
I have offered to make the behaviour requested dependent on a configuration parameter but apparently this is not sufficient.
