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
