Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints
Date
Msg-id e31eccb0-d324-0f21-67b6-4e621c103f76@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints  (Nico Williams <nico@cryptonector.com>)
Responses Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints  (Nico Williams <nico@cryptonector.com>)
List 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] ucs_wcwidth vintage
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Linking libpq statically to libssl