From: | Nico Williams <nico(at)cryptonector(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Add ALWAYS DEFERRED option for constraints |
Date: | 2017-11-03 17:56:28 |
Message-ID: | 20171103175627.GX4496@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 03, 2017 at 01:41:45PM -0400, Peter Eisentraut wrote:
> On 11/2/17 16:54, Nico Williams wrote:
> > Replacing condeferred and condeferrable with a char columns also
> > occurred to me, and though I assume backwards-incompatible changes to
> > pg_catalog tables are fair game, I assumed everyone would prefer
> > avoiding such changes where possible.
>
> I don't think there is an overriding mandate to avoid such catalog
> changes. Consider old clients that don't know about your new column.
> They might look at the catalog entries and derive information about a
> constraint, not being aware that there is additional information in
> another column that overrides that. So in such cases it's arguably
> better to make a break.
Makes sense.
> (In any case, it might be worth waiting for a review of the rest of the
> patch before taking on a significant rewrite of the catalog structures.)
I'll wait then :)
When you're done with that I'll make this change (replacing those three
bool columns with a single char column).
> > Hmmm, must I do anything special about _downgrades_? Does PostgreSQL
> > support downgrades?
>
> no
Oh good. Thanks for clarifying that.
Nico
--
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2017-11-03 18:09:00 | Where is it documented what role executes constraint triggers? |
Previous Message | Peter Eisentraut | 2017-11-03 17:55:03 | Re: Dynamic result sets from procedures |