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 6ae312d4-d3b2-a999-cb15-91a028229c86@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
I haven't really thought about this feature too hard; I just want to
give you a couple of code comments.

I think the catalog structure, and relatedly also the parser structures,
could be made more compact.  We currently have condeferrable and
condeferred to represent three valid states (NOT DEFERRABLE, DEFERRABLE
INITIALLY IMMEDIATE, DEFERRABLE INITIALLY DEFERRED).  You are adding
conalwaysdeferred, but you are adding only additional state (ALWAYS
DEFERRED).  So we end up with three bool fields to represent four
states.  I think this should all be rolled into one char field with four
states.

In psql and pg_dump, if you are query new catalog fields, you need to
have a version check to have a different query for >=PG11.  (This would
likely apply whether you adopt my suggestion above or not.)

Maybe a test case in pg_dump would be useful.

Other than that, this looks like a pretty complete patch.

-- 
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] Re: PANIC: invalid index offnum: 186 when processingBRIN indexes in VACUUM
Next
From: Nico Williams
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11