Robert Haas wrote: <blockquote cite="mid:603c8f070912021104g32f14915rec242e0ecde3ae45@mail.gmail.com" type="cite"><pre
wrap="">OnWed, Dec 2, 2009 at 1:56 PM, Greg Smith <a class="moz-txt-link-rfc2396E"
href="mailto:greg@2ndquadrant.com"><greg@2ndquadrant.com></a>wrote: </pre><blockquote type="cite"><pre
wrap="">There'sno reason the associated catalog support had to ship with the old
version. You can always modify the catalog after initdb, but before running
the pre-upgrade utility. pg_migrator might make that change for you. </pre></blockquote><pre wrap="">
Uh, really? I don't think that's possible at all. </pre></blockquote> Worst case just to get this bootstrapped: you
installa new table with the added bits. Old version page upgrader accounts for itself there. pg_migrator dumps that
dataand then loads it into its new, correct home on the newer version. There's already stuff like that being done
anyway--dumpingthings from the old catalog and inserting into the new one--and if the origin is actually an add-on
ratherthan an original catalog page it doesn't really matter. As long as the new version can see the info it needs in
itscatalog it doesn't matter how it got to there; that's the one that needs to check the migration status before it can
accessthings outside of the catalog.<br /><br /><pre class="moz-signature" cols="72">--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
<a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a
class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a>
</pre>
