On Monday 08 July 2002 03:20 pm, Jan Wieck wrote:
> Zeugswetter Andreas SB SD wrote:
> > Unless it dumps binary representation of columns, a standalone dumper
> > would still need to load all the output function shared libs for custom
> > types (or not support custom types which would imho not be good).
> And now we change the internal representation of NUMERIC to a short
> integer array holding the number in base 10,000 and what exactly does
> the standalone dumpster do with our data?
What does a standard dump/restore do then as well? Is the restore process
complicated by a rebuild of the function(s) involved in custom types? This,
IMHO, is a pathological case even for a standard dump/restore. Someone doing
this sort of thing is going to have more to do that a simple package upgrade.
> 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.
This is the best dialog yet on the issue of upgrading. Keep it coming! :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11