Re: [PATCH] Add ALWAYS DEFERRED option for constraints

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Nico Williams <nico(at)cryptonector(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Add ALWAYS DEFERRED option for constraints
Date: 2017-11-03 17:41:45
Message-ID: e31eccb0-d324-0f21-67b6-4e621c103f76@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

(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.)

> Hmmm, must I do anything special about _downgrades_? Does PostgreSQL
> support downgrades?

no

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-11-03 17:42:42 Re: Linking libpq statically to libssl
Previous Message Alvaro Herrera 2017-11-03 17:38:27 Re: ucs_wcwidth vintage