Re: Mark a transaction uncommittable

From: Gurjeet Singh <gurjeet(at)singh(dot)im>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Mark a transaction uncommittable
Date: 2023-06-05 20:24:26
Message-ID: CABwTF4Un4d9_wE63Tk96_x8hTAz6Lc2--EtKhq3ybWKno3r=ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 5, 2023 at 12:32 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Mon, 2023-06-05 at 00:22 -0700, Gurjeet Singh wrote:
> > On Sat, Apr 22, 2023 at 8:01 AM Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
> > >
> > > This is a proposal for a new transaction characteristic. I haven't
> > > written any code, yet, and am interested in hearing if others may find
> > > this feature useful.
> >
> > Please see attached the patch that introduces this new feature.
>
> Can you explain why *you* would find this feature useful?

The idea came to me while I was reading a blog post, where the author
had to go to great lengths to explain to the reader why the queries
would be disastrous, if run on production database, and that they
should run those queries inside a transaction, and they _must_
rollback the transaction.

Having written my fair share of tutorials, and blogs, I know how
helpful it would be to start a transaction that the reader can't
accidentally commit.

As others have noted in this thread, this feature can be useful in
other situations, as well, like when you're trying to export a
sanitized copy of a production database. Especially in such a
situation you do not want those sanitization operations to ever be
committed on the source database.

Best regards,
Gurjeet
http://Gurje.et

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2023-06-05 20:27:52 Re: Mark a transaction uncommittable
Previous Message Joe Conway 2023-06-05 20:08:24 Re: Let's make PostgreSQL multi-threaded