On Tue, 2002-07-09 at 00:20, Jan Wieck wrote:
> 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!
This brings us back to my original proposal : this "external tool" needs
to be either a full postgres backend with added DUMP command or
something that can use a (possibly single-user) backend as either a
library or, yes, a "backend" ;)
---------------------
Hannu