Re: Migrating from 9.2.4 to 9.3.0 with XML DOCTYPE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tim Kane <tim(dot)kane(at)gmail(dot)com>
Cc: pgsql-general General <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Migrating from 9.2.4 to 9.3.0 with XML DOCTYPE
Date: 2014-06-04 15:06:26
Message-ID: 20509.1401894386@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tim Kane <tim(dot)kane(at)gmail(dot)com> writes:
> Im migrating a database from 9.2.4 to 9.3.0 and encountering an issue with
> an XML field failing to restore.

Hm, can you restore it into 9.2 either?

AFAICS, pg_dump has absolutely no idea that it should be worried about the
value of xmloption, despite the fact that that setting affects what is
considered valid XML data. What's worse, even if it were attempting to do
something about xmloption, I don't see how it could deal with a case like
this where you have different values inside the same database that require
two different settings in order to parse.

This isn't a 9.3.x bug, it's an aboriginal misdesign of the XML datatype.
Not sure what we can do about it at this point. Perhaps we could invent
a "document_or_content" setting that would tell xml_in to accept either
case? And then have pg_dump force that setting to be used during restore?

regards, tom lane

PS: BTW, I agree with the advice expressed by David J: under no
circumstances put any data you care about on 9.3.0. That release
was rather a disaster from a quality-control standpoint :-(
But that's unrelated to your XML issue.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bill Mitchell 2014-06-04 15:38:24 Partial solution to observed " MultiXactId ### has not been created yet -- apparent wraparound" issue with newly upgraded db
Previous Message Adrian Klaver 2014-06-04 13:34:13 Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-04 15:08:42 Re: pg_control is missing a field for LOBLKSIZE
Previous Message Andres Freund 2014-06-04 15:03:05 Re: pg_control is missing a field for LOBLKSIZE