Zeugswetter Andreas SB SD wrote:
>
> > No, what I envisioned was a standalone dumper that can produce dump output
> > without having a backend at all. If this dumper knows about the various
> > binary formats, and knows how to get my data into a form I can then restore
> > reliably, I will be satisfied. If it can be easily automated so much the
> > better. Doing it table by table would be ok as well.
>
> 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?
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!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
