On 05/29/2018 05:01 PM, Alvaro Herrera wrote:
> On 2018-May-29, Stuart McGraw wrote:
>
>> Alternatively if there were a setting to tell Postgresql to
>> follow the SQL standard behavior of overwriting rather stacking
>> savepoints, that too would also solve my current problem I think.
>> Perhaps it is just my limited experience but the former behavior
>> has always seemed more useful in practice than the latter.
>
> I think if what we're doing breaks the semantics of the SQL spec, we're
> definitely open to changing our behavior.
My comment was based on the statement in the Postqresql docs for SAVEPOINT:
"SQL requires a savepoint to be destroyed automatically when another
savepoint with the same name is established. In PostgreSQL, the old
savepoint is kept, though only the more recent one will be used when
rolling back or releasing. (Releasing the newer savepoint with RELEASE
SAVEPOINT will cause the older one to again become accessible to ROLLBACK
TO SAVEPOINT and RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL
conforming."
> But that wouldn't solve your
> problem today. What I think could solve your problem today is a
> C-language extension that uses xact.c callbacks in order to expose a
> list that you can query from user space.
Even that won't solve it unless I can find someone who has already
written it and is willing to share it and my Googling hasn't found
anything yet. :-(
