Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Yes, I now think that saving the SET commands that are ignored in a
> > > transaction and running them _after_ the transaction completes may be
> > > the best thing.
> >
> > No, that's just plain ridiculous. If you want to change the semantics
>
> No more ridiculous than what we have now.
>
> > of SET, then make it work *correctly*, viz like an SQL statement: roll
> > it back on transaction abort. Otherwise leave it alone.
>
> I am not going to leave it alone based only on your say-so, Tom.
I have to agree with Tom here. It's not right to hack up SET to be accepted in transaction abort state. Nor is it
rightto queue up SET requests then. If those queued SET's lead to errors, when do you report them? On
ROLLBACK?
If at all, SET commands should behave like everything else. If done inside a transaction, they have to
rollback.
> > > If we don't somehow get this to work, how do we do timeouts, which we
> > > all know we should have?
> >
> > This is utterly unrelated to timeouts. With or without any changes in
> > SET behavior, JDBC would need to issue a SET after completion of the
> > transaction if they wanted to revert a query_timeout variable to the
> > no-timeout state.
>
> "Utterly unrelated?" No. If we can get SET to work properly in
> transactions, jdbc can cleanly issue SET timeout=4, statement, SET
> timeout=0. Without it, using SET for timeout is a problem. That's how
> we got to this issue in the first place.
Could we get out of this by defining that "timeout" is automatically reset at next statement end? So that
theentire thing is
SET timeout=4; SELECT ...; -- We're back in no-timeout
And that it doesn't matter if we're in a transaction, if the statement aborts, yadda yadda...
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
