Re: Constraint documentation

From: Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>
To: peter(dot)eisentraut(at)2ndquadrant(dot)com
Cc: bpd0018(at)gmail(dot)com, vik(dot)fearing(at)2ndquadrant(dot)com, coelho(at)cri(dot)ensmp(dot)fr, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Constraint documentation
Date: 2018-08-07 12:29:43
Message-ID: CAB_COdiF1OLUay4Cu_XdKevNPD0cFeC1QnzN-kNYm9JuprKWkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Peter,

I understand what you're pointing at and I agree that it could be a good
thing to be able to dump/restore a table without problem.

My point was that check constraints weren't supposed to be used that way
theorically (or maybe i'm mistaken ?) so I thought maybe we should just
inform the user that this kind of use of a check constraint is a misuse of
that feature.

Maybe it's not the right way to say it. I can remove the part about pg_dump
if it's too confusing...

Regards,

Lætitia

Le mer. 27 juin 2018 à 08:44, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> a écrit :

> On 6/26/18 09:49, Lætitia Avrot wrote:
> > + <note>
> > + <para>
> > + Check constraints are not designed to enforce business rules
> across tables.
> > + Avoid using check constraints with a function accessing other
> tables and
> > + use <xref linkend="triggers"/> instead. Although PostgreSQL won't
> prevent you
> > + from doing so, beware that dumps generated by
> <application>pg_dump</application>
> > + or <application>pg_dumpall</application> may be hard
> > + to restore because of such checks, as the underlying dependencies
> are not
> > + taken into account.
> > + </para>
> > + </note>
>
> In a way, I think this is attacking the wrong problem. It is saying
> that you should use triggers instead of check constraints in certain
> circumstances. But triggers are also used as an implementation detail
> of constraints. While it currently doesn't exist, a deferrable check
> constraint would probably be implemented as a trigger. It's not the
> triggerness that fixes this problem. The problem is more generally that
> if a function uses a table, then pg_dump can't know about the ordering.
> It happens to work for triggers because triggers are dumped after all
> tables, as a performance optimization, and we could very well dump check
> constraints differently as well.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
*Think! Do you really need to print this email ? *
*There is no Planet B.*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2018-08-07 12:36:16 Re: [HACKERS] Cached plans and statement generalization
Previous Message Tomas Vondra 2018-08-07 12:25:18 Re: Standby trying "restore_command" before local WAL