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   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to