| 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: | Whole Thread | Raw Message | 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
| 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 |