Tom Lane wrote:
> >>> ... I think we
> >>> should just do an automatic COMMIT if it is the first statement of a
> >>> transaction, and if not, throw the same error we used to throw. We are
> >>> performing autocommit for SET at the start of a transaction now anyway,
> >>> so it isn't totally strange to do it for TRUNCATE, etc. too.
> >>
> >> We can go with the auto-COMMIT idea for statements that are invoked at
> >> the outer interactive level,
>
> What I just committed uses your idea of auto-committing TRUNCATE et al,
> but now that I review the thread I think that everyone else thought that
> that was a dangerous idea. How do you feel about simply throwing an error
> in autocommit-off mode, instead? (At least it's a localized change now)
Yes, I saw more votes to not allow it, as you said, but turning off
autocommit just seemed really strange to me, because then they have to
turn it on again to continue. It just seemed strange to tell them to
set something to execute a command.
Maybe we can throw a WARNING when autocommit is on. Would that make
everyone happy?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
