Edmund Horner <ejr...@gmail.com> writes:
> On Fri, 15 Mar 2019 at 18:18, Chapman Flack <c...@anastigmatix.net> wrote:
>> What exactly is a savepointLevel?
>>
>> They seem to have been there for 15 years[1], diligently copied from
>> parent transactions to children, fastidiously checked to avoid crossing
>> a level on rollback or release, but does anything ever change the level
>> from its initial value? I'm drawing a blank[2].
> I had a look too, checking for uses where savepointLevel might be set
> as part of a struct initialisation. I can't find any.
Yeah, I think that the field's basically been there for future use
since day one. The SQL spec discusses savepoint levels, but as far
as I could find in some desultory searching, the only way to actually
change to a new savepoint level is to enter a function or procedure that
has the NEW SAVEPOINT LEVEL property, which is syntax we don't have.
Even though the code's dead today, I'm disinclined to remove it;
now that we have procedures, the need to treat savepoint levels
as a real feature might be closer upon us than it has been. It
doesn't look like it's costing any significant amount of cycles
or code anyhow.
(On the other hand, maybe this is something we'd never implement.
Attaching savepoint level control to the callee, rather than the
caller, seems pretty weird to me. AFAICS the point of a new
savepoint level would be to prevent the function from messing
with savepoints of the outer level, so I'd think what you'd want
is syntax whereby the caller can protect itself against the
callee doing that.)
regards, tom lane
