Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 01:59:00PM -0400, Andrew Dunstan wrote:
> >
> > Pascal Meunier wrote:
> > >Thanks for answering; I appreciate it, as well as the efforts of all the
> > >people who contributed to this database that I now use in my projects.
> > >
> > >However, I feel that making a decision based on the number of prior and
> > >possible future complaints is a poor excuse to not do the right thing. A
> > >low number of prior complaints simply suggests lax security audits of
> > >default behaviors.
> > >
> >
> >
> > At the very least we would need a way of getting the current behaviour,
> > if we are not to break existing applications.
> >
> > People have a reasonable expectation that a dump and reload will work,
> > and that can't be dismissed as cavalierly as this.
> >
> > Maybe a config file option would do the trick, or maybe an option to
> > pg_dump / pg_dumpall to make it generate the extra GRANT statement that
> > would be required.
>
> This pg_dump issue keeps biting us in the rear... I think at the very
> least we should have a means for a dump file to tell the backend that
> it's about to process a dump file generated by version XYZ. That at
> least gives us the ability to handle prior version incompatibilites.
I have always agreed with that. I would just have a GUC that pg_dump
would set that could be used in the future for conditional behavior.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
