On Fri, 14 Feb 2020 at 14:37, Robert Haas <robertmh...@gmail.com> wrote:
> 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. Dave Cramer www.postgres.rocks
