Re: [GENERAL] Migrating from 9.2.4 to 9.3.0 with XML DOCTYPE

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

>
>
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>
> 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?

This sounds reasonable. My use case is purely as a document store, with the
ability to perform xml parse functions against it – as such, I’m not
concerned wether it’s a document or content – hence why we have both types
recorded against that field.

For the minute, I’m getting around the restore problem by mangling the dump
such that the table is created using the text type rather than xml. This at
least gets the data onto a 9.3 cluster, even if it’s cosmetically
represented as text instead of xml. I can worry about the document vs
content problem at a later stage.

>
> 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.

Ack. Thanks for the info. I’ll push the upgrade-path agenda a little harder.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2014-06-04 16:21:55 Re: pg_largeobject high overhead
Previous 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2014-06-04 16:16:16 Re: psql: show only failed queries
Previous Message Pavel Stehule 2014-06-04 15:54:29 Re: psql: show only failed queries