Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group