| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Lamar Owen" <lamar(dot)owen(at)wgcr(dot)org>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Hannu Krosing" <hannu(at)tm(dot)ee> |
| Cc: | "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "HACKERS" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: (A) native Windows port |
| Date: | 2002-07-08 13:15:00 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961E11@m0114.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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).
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Karel Zak | 2002-07-08 13:33:35 | Re: Proposal: CREATE CONVERSION |
| Previous Message | Patrick Macdonald | 2002-07-08 13:10:30 | Re: Issues Outstanding for Point In Time Recovery (PITR) |