Re: Speed dblink using alternate libpq tuple storage

Marko Kreen <markokr(at)gmail(dot)com> writes:
> Seems we both lost sight of actual usage scenario for the early-exit
> logic - that both callback and upper-level code *must* cooperate
> for it to be useful. Instead, we designed API for non-cooperating case,
> which is wrong.

Exactly. So you need an extra result state, or something isomorphic.

> So the proper approach would be to have new API call, designed to
> handle it, and allow early-exit only from there.

> That would also avoid any breakage of old APIs. Also it would avoid
> any accidental data loss, if the user code does not have exactly
> right sequence of calls.

> How about PQisBusy2(), which returns '2' when early-exit is requested?
> Please suggest something better...

My proposal is way better than that. You apparently aren't absorbing my
point, which is that making this behavior unusable with every existing
API (whether intentionally or by oversight) isn't an improvement.
The row processor needs to be able to do this *without* assuming a
particular usage style, and most particularly it should not force people
to use async mode.

An alternative that I'd prefer to that one is to get rid of the
suspension return mode altogether. However, that leaves us needing
to document what it means to longjmp out of a row processor without
having any comparable API concept, so I don't really find it better.

regards, tom lane