Re: pg_dump additional options for performance

From: David BOURIAUD <david(dot)bouriaud(at)ac-rouen(dot)fr>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-02-26 15:23:18
Message-ID: 200802261623.21062.david.bouriaud@ac-rouen.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le mardi 26 février 2008, Tom Lane a écrit :
>
> In short, what I think we need here is just some more conveniently
> defined extraction filter switches than --schema-only and --data-only.
> There's no need for any fundamental change to pg_dump's architecture.

Forgive me if what I will say bellow is completly pointless, but I think at
this point that the base of this discussion might be wrong. If the decision
made here is to keep pg_dump simple, then maybe that it could be left as it
is, and create another tool just to extract some parts of a database, either
schema or data.
As far as I understand what is said here, pg_dump is thought to be a tool used
to make a backup of a database to use it somewhere else. So let it be as it
is.
What I intendeed to mean in my first post, is that it would be great to have a
tool that could let one get a partial dump of a database at one time, so as
to modify (or not) and to alter the database afterward (or not).

I use to work on many databases at a time, and sometime, I have to quickly fix
a function, add a trigger to a table... Sometime I create a sql file and save
my work before passing the command set to psql, but sometimes I don't have
much time and type in the code directly in psql.
So far so good, the code works, until a problem is found, and then, I don't
have any source file to work on...unless I use pg_dump and search the so big
file for the code I want to modify.
I hope you see what I mean. Since the idea whas to dump informations about the
structure of a table, function type or whatever object one could want from
the base, I asked for options for pg_dump, but maybe a new tool (based on
pg_dump ?) could satisfy everyone ?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-02-26 15:25:27 Re: Bulk loading performance improvements
Previous Message Simon Riggs 2008-02-26 15:15:59 Re: pg_dump additional options for performance