Re: pg_dump/all doesn't output database ACLs (v7.3.4)

On Mon, 08 Sep 2003, Tom Lane wrote:

> Ben Grimm <ben(at)zaeon(dot)com> writes:
> > On Thu, 04 Sep 2003, Tom Lane wrote:
> >> Ben Grimm <ben(at)zaeon(dot)com> writes:
> >>> I haven't tried the 7.4 beta, so it may be fixed there - but in
> >>> 7.3.4, pg_dumpall doesn't output global database ACL's.
> >>
> >> This is fixed for 7.4.
>
> > Is there a patch to backport this to the 7.3 series?
>
> No, but you can use 7.4's pg_dumpall against your 7.3 database.

Sure, I tried it right away when you mentioned that it was fixed for 7.4.
So doing an upgrade won't give any problems relating to database acl's,
but we'll still have issues with user owned schemas.

So.. what about all the people that are starting to use schemas now that
they're available? For example, we went from about 1500 logical users
using a few dozen tables to 1500 real users using schemas. Now, all of
the data that is owned by a given user - rather than being mixed with all
of the other users data - is consolidated into inherited versions of tables
from the public schema. It all works quite well, and I'm not sure we'd
have been able to do it this way with any other dbms. Of course, now we
have 86,000 rows in pg_class and pg_dump takes 3x longer to run than it
used to. What I'm getting at is that we use a development server that is
loaded from a copy of the production server, and after we designed and
tested the migration, redesigned the application to fit the new model, and
finally did our application/schema upgrade a couple of weeks back we went
to copy the new production database back to the development server. I was
really surprised to find the bugs I did - and worried to know that the
nightly backups I take are not going to be as simple to restore as just
running 'bzcat backup.bz2 | psql'. I can make it work so it's not tragic
for me; but I wonder about all the other people who are using schemas
and/or database level permissions in the 7.3 series.