From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ryan(at)rustprooflabs(dot)com |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15342: pg_dump - XML with mixed content types generates invalid backup file |
Date: | 2018-08-23 15:24:55 |
Message-ID: | 27956.1535037895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> It seems that `pg_dump` is unable to provide a reliable database backups
> that include specific combinations of XML data. The following SQL Fiddle
> creates a table with three rows of XML data. The first row, "Document, no
> DOCTYPE" is the only row of the three that will always load from a backup
> from `pg_dump`. I've tried this one a few sub-versions of 9.6 and 9.5.
Hm. So there are two problems here: pg_dump neglects to force a safe
value of xmloption for the restore step, plus there doesn't seem to be
a safe value for it to force :-(. The first part of that is trivial
to fix, the second perhaps not so much. However, the fine manual quoth
(in 8.13 XML Type)
SET xmloption TO { DOCUMENT | CONTENT };
The default is CONTENT, so all forms of XML data are allowed.
which makes it seem that the CONTENT setting was intended to work for
this. Perhaps somebody just got overenthusiastic about throwing errors?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-08-23 22:16:14 | Re: BUG #15347: Unaccent for greek characters does not work |
Previous Message | Pavel Stehule | 2018-08-23 14:57:48 | Re: 11 beta 3 / ROLLBACK TO SAVEPOINT regression in PLPGSQL |