| From: | Magnus Hagander <mha(at)sollentuna(dot)net> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mike Mascari <mascarm(at)mascari(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | RE: I remember why I suggested CREATE FUNCTION...AS NUL L |
| Date: | 2000-09-11 10:57:14 |
| Message-ID: | 215896B6B5E1CF11BC5600805FFEA82103D97DAA@sirius.edu.sollentuna.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 2) Change pg_dump to walk through dependencies?
>
> The trouble with that is that dependency analysis is a monstrous job,
> and one that would make pg_dump even more fragile and backend-version-
> dependent than it is now.
One way to get around that might be to make the dumping routine a part
of the backend instead of a frontend. This is what at least MS SQL does.
So I can do for example:
BACKUP DATABASE mydb TO DISK 'c:\foo.dump'
or, if I want to send the backup directly to my backup program
BACKUP DATABASE mydb TO PIPE 'somepipe'
Then to reload it I just do
RESTORE DATABASE mydb FROM DISK 'c:\foo.dump'
Doing this might also help with permissions issues, since the entire
process can be run inside tbe backend (and skip security checks at some
points, assuming that it was a user with backup permissions who started
the operation)?
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin A. Marques | 2000-09-11 11:14:24 | problems with GRANT on Solaris 8 |
| Previous Message | Karel Zak | 2000-09-11 10:00:23 | Re: I'm unable to access CVS |