On Sat, 29 May 2004, Alvaro Herrera wrote:
> On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote:
>
> > Also related, although START TRANSACTION (specifying isolation level or
> > read onlyness as part) is currently defined to act as if set transaction
> > was used, it seems really odd that the settings would leak to the outer
> > translation even on a commit and that you can't specify isolation level -
> > even if it's the same level - if the outer transaction has done any
> > queries.
>
> Hmm ... isolation level and read onlyness was discussed last year and I
> think we had a working design. I'll look into my archives.
>
>
> > BTW: For the deferred trigger stuff, I am guessing you haven't touched
> > that at all in the current patch?
> >
> > I wonder if the following would work assuming that we want deferred
> > triggers to run at outer transaction end?
>
> Ah, this seems to work. I'll implement it and I'll let you know how it
> goes.
Note, that I think you'd still need to do some kind of tiered thing for
set constraint status, but I didn't think about that yet.
> > I think it might be possible to do the queue deallocation for
> > subtransaction abort with appropriate context work (each one gets a
> > context under its parent's and on abort it's removed and on commit it's
> > not until you reach the outermost?) but I haven't though about it enough.
>
> Actually there already is such a global context and I think it's appropiate
> here.
We probably want to be able to easily remove all the items for an aborted
sub transaction, and I was hoping that there might be an easy way to use
the contexts to do that rather than manually trolling through deallocating
entries from the queue.
