Re: One more option for pg_dump...

From: "Brendan Jurd" <direvus(at)gmail(dot)com>
To: "David BOURIAUD" <david(dot)bouriaud(at)ac-rouen(dot)fr>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: One more option for pg_dump...
Date: 2008-02-27 02:05:44
Message-ID: 37ed240d0802261805q4bfaf75yc1ab346583aafd48@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 26, 2008 at 12:48 AM, David BOURIAUD
<david(dot)bouriaud(at)ac-rouen(dot)fr> wrote:
> I haven't found any option to dump any user-defined function stored in a
> database, unless doing a pg_dump -D -s database, but so far one would get the
> definitions of the tables, the permissions, the triggers, and so on, so when
> you have a big schema, it is not much user friendly to do a full dump to
> change one or two lines of code in a function.

Currently the intelligence about how to "dump" a function (that is,
take a pg_proc row and come up with a CREATE FUNCTION statement) is
coded directly into pg_dump.

Wouldn't it be more helpful if this was provided as a function by the
backend? That way you wouldn't have to mess with pg_dump at all, if
you were in the OP's situation and just wanted to grab the definition
for one (or several) functions.

You could just pull up a psql session and do a "select
pg_func_def(regproc);" and there you go, one fully formed CREATE
FUNCTION statement.

It leaves the question of what to do about COMMENTs up in the air,
since you would need to dump it as two separate statements, but I
don't think that is as important as being able to pull arbitrary
object defs from the database without resorting to kludgery.

Regards,
BJ

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2008-02-27 02:06:05 Re: Mailing list failure WAS: Including PL/PgSQL by default
Previous Message Gregory Stark 2008-02-27 02:03:45 Re: pg_dump additional options for performance