From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Another nasty pg_dump problem |
Date: | 2003-08-01 10:25:18 |
Message-ID: | Pine.LNX.4.56.0308011223590.1793@krusty.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> I've repaired this in CVS tip. While testing it, though, I notice that
> CVS-tip pg_dump puts out useless commands
>
> REVOKE ALL ON SCHEMA public FROM PUBLIC;
> GRANT ALL ON SCHEMA public TO PUBLIC;
>
> which are not generated when dumping from 7.3. The reason evidently is
> that this check in pg_dump.c no longer works:
This could be fixed, but note that elsewhere we use
/*
* Always start with REVOKE ALL FROM PUBLIC, so that we don't have to
* wire-in knowledge about the default public privileges for different
* kinds of objects.
*/
appendPQExpBuffer(firstsql, "REVOKE ALL ON %s %s FROM PUBLIC;\n",
type, name);
So maybe this isn't such a bad state after all.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2003-08-01 10:56:35 | Re: python interface |
Previous Message | Peter Eisentraut | 2003-08-01 09:40:50 | Re: contrib compilation probs |