On Tue, 2002-07-09 at 17:19, Lamar Owen wrote:
> On Monday 08 July 2002 03:20 pm, Jan Wieck wrote:
> > Another good example: let's add a field to some parsenode struct (was
> > there a release where this didn't happen?). This causes the NodeOut()
> > results to become a little different, which actually changes the textual
> > content of a likely toasted pg_rewrite attribute. Stored compressed and
> > sliced. I am quite a bit familiar with TOAST and the rewrite system.
> > Yet, someone has to help me a little to understand how we can do this
> > conversion in binary on the fly with an external tool. Especially where
> > this conversion results in different raw and compressed sizes of the
> > TOASTed attribute, which has to propagate up into the TOAST reference in
> > the main table ... not to speak of possible required block splits in the
> > toast table and index because of needing one more slice!
>
> This is more difficult, certainly. Martijn, how does pg_fsck handle such
> things now?
>
> Again, this tool has utility outside upgrading. And I'm talking about dumping
> the binary down to ASCII to be restored, not binary to binary on the fly.
You seem to be talking about pg_dump + old backend, no ? ;)
For me it seems a given that you need old binary-reading code to read
old binary format data. The most convenient place to keep it is inside
an old backend.
It may be possible to migrate simple user table data from old version to
new, but it gets complicated real fast for most other things, especially
for stuff in system tables.
---------------
Hannu
