Re: Error on failed COMMIT

On Fri, 14 Feb 2020 at 14:37, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer <davecramer(at)postgres(dot)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