Re: pg_dump bug?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: ohp(at)pyrenet(dot)fr
Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump bug?
Date: 2003-09-01 01:51:02
Message-ID: 200309010151.h811p2g25835@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ohp(at)pyrenet(dot)fr wrote:
> Hi all,
>
> This is on 7.3.4
> I had altered a user like this:
> alter user set search_path = shema1,public
>
> Then I had to pgdumpall, re-initdb and restore every thing.
>
> The alter user did'nt get through. and broke my app.

Yes, it seems pg_dump doesn't dump per-database alter information, only
pg_dumpall does. That information is considered global to the cluster,
rather than per-database.

Should we throw a warning or dump that info in pg_dump?

> Is it a pg_dump bug? I haven't tested on 7.4b
>
> BTW, would'nt it be more logical if we could set the search_path on a
> database basis. ALTER DATABASE doesn't seem to support it
> Regards,

I just tried it in 7.4beta and it worked:

test=> alter database test set search_path to 'public';

When I disconnect and reconnect:

test=> show search_path;
search_path
-------------
public
(1 row)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2003-09-01 02:37:58 Re: Linux2.6 overcommit behaviour
Previous Message Bruce Momjian 2003-09-01 01:30:52 Re: Linux2.6 overcommit behaviour