Re: [HACKERS] Another nasty pg_dump problem

2003-08-01 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > 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. > */

Re: [HACKERS] Another nasty pg_dump problem

2003-08-01 Thread Peter Eisentraut
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 evi

Re: [HACKERS] Another nasty pg_dump problem

2003-07-31 Thread Tom Lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > On my 7.3 server: > REVOKE ALL ON TABLE exercise_activities FROM PUBLIC; > GRANT ALL ON TABLE exercise_activities TO chriskl; > GRANT SELECT ON TABLE exercise_activities TO "au-diary"; > GRANT SELECT ON TABLE exercise_activities TO "au-php";

[HACKERS] Another nasty pg_dump problem

2003-07-08 Thread Christopher Kings-Lynne
On my 7.3 server: australia=# \dp exercise_activities Access privileges for database "australia" Schema |Table|Access privileges +-+- public | exercise_