Re: One more option for pg_dump... - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: One more option for pg_dump...
Date
Msg-id 37ed240d0802261805q4bfaf75yc1ab346583aafd48@mail.gmail.com
Whole thread Raw
In response to One more option for pg_dump...  (David BOURIAUD <david.bouriaud@ac-rouen.fr>)
Responses Re: One more option for pg_dump...  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Tue, Feb 26, 2008 at 12:48 AM, David BOURIAUD
<david.bouriaud@ac-rouen.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


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: pg_dump additional options for performance
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Mailing list failure WAS: Including PL/PgSQL by default