"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Tom Lane <t...@sss.pgh.pa.us> wrote: >> Also, that code is set so that it will throw an error even if >> you're assigning the currently active setting, which maybe is >> overly strict? Not sure. > The standard is tricky to read, but my reading of it is that only > "LOCAL" changes are allowed after the transaction is underway (which > I *think* effectively means a subtransaction), and those can't make > the setting less strict -- you're allowed to specify the same level > or more strict. There would be no harm from the perspective of > anything I'm working on to allow an in-progress transaction to be > set to what it already has, but that seems to invite confusion and > error more than provide a helpful feature, as far as I can tell. > I'm inclined not to allow it except at the start of a > subtransaction, but don't feel strongly about it.
Hmm ... (1) If the standard says that you're allowed to apply a redundant setting, I think we'd better accept that. (2) I'm not thrilled about the idea of tracking the equivalent of FirstSnapshotSet for each subtransaction, which I think would be necessary infrastructure to error-check this as tightly as you seem to have in mind. I'd prefer to be a bit laxer in order to have less overhead for what is in the end just nanny-ism. So the implementation I had in mind would allow SET TRANSACTION operations to occur later in a subxact, as long as they were redundant and weren't actually trying to change the active value. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers