Re: pg_dump: creates dumps that cannot be restored

From: Thorsten Glaser <t(dot)glaser(at)tarent(dot)de>
To: pgsql-general(at)postgresql(dot)org, 859033(at)bugs(dot)debian(dot)org
Cc: Andreas Buschka <a(dot)buschka(at)tarent(dot)de>
Subject: Re: pg_dump: creates dumps that cannot be restored
Date: 2017-04-07 18:10:13
Message-ID: alpine.DEB.2.20.1704072007570.31990@tglase-nb.lan.tarent.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi *,

I’ve tried both setting the constraints temporarily to invalid (works)
and converting (painstakingly slow, as this is new for me) to triggers
(also works). Both can be dumped and restored.

I’ve also found out that I probably can ship the schema update that
converts the CHECK constraint to a trigger to the customer Right Now™
so I’ll fix this actual schema bug. I still find the CHECK constraint
to be a more natural way to express what I want, though.

I’m attaching the trigger conversion to help anyone else who does this
(and to invite feedback should there be anything I could improve).

Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Attachment Content-Type Size
testcase.sql application/x-sql 2.6 KB

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tim Nelson 2017-04-07 20:25:02 SELECT and RowExclusiveLock
Previous Message Guillaume Lelarge 2017-04-07 15:30:55 Re: [ADMIN] calculating table and index size