Re: [PATCH] session_replication_role = replica with TRUNCATE

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] session_replication_role = replica with TRUNCATE
Date: 2017-12-30 07:42:10
Message-ID: CAMsr+YEJSPzrRjVK0ewAaraGcQWpBAfzxv0zudctBiTQx5hnGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30 December 2017 at 03:32, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
wrote:

> On 29/12/17 16:53, Marco Nenciarini wrote:
> > Il 29/12/17 15:14, Petr Jelinek ha scritto:
> >>
> >> May be worth documenting that the session_replication_role also affects
> >> TRUNCATE's interaction with FKs in config.sgml.
> >>
> >
> > The current documentation of session_replication_role GUC is:
> >
> > Controls firing of replication-related triggers and rules for the
> > current session. Setting this variable requires superuser privilege
> > and results in discarding any previously cached query plans.
> > Possible values are origin (the default), replica and local.
> > See ALTER TABLE for more information.
> >
> > It doesn't speak about foreign keys or referential integrity, but only
> > about triggers and rules. I don't think that it's worth to add a special
> > case for truncate, unless we want to expand/rewrite the documentation to
> > specify all the effects in the details.
> >
>
> The effects on foreign keys is implied by the fact that for DML it's
> implemented using triggers, but that's not true for TRUNCATE. In any
> case it does not hurt to mention the FKs explicitly rather than
> implicitly here.

Yeah. I'd argue that's an oversight in the current docs that "can cause FK
violations" isn't mentioned. That's kind of important, and FKs being
triggers is implementation detail we shouldn't be relying on users to know.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2017-12-30 09:18:02 Re: New gist vacuum.
Previous Message Tom Lane 2017-12-30 03:47:30 CONSTANT/NOT NULL/initializer properties for plpgsql record variables