Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
<ste...@kaltenbrunner.cc> wrote:
that will pretty much defeat the purpose for most use cases i guess because
people will dump with the defaults and only discover the problem after the
fact.
Well, if you dump in custom format, it could be useful to be able to
do this on pg_restore time. Not having followed this thread in detail,
but would that work? That would be a much more useful option...
Personally, I feel that *both* would be useful, and I'd be unhappy with
any implementation which didn't include both. That being said, the
users that are likely to run into this problem will, imnsho, be much
happier if we tell them "oh, just flip option X in your pg_dump" than
"go edit the .sql file with vi and find where the problem cases are and
fix them". Obviously, we should caveat our response that this will only
fix the pg_dump/restore problem and that their applications may need to
be fixed.
That is exactly what I think is "to big a promise" - I don't think we
can actually guarantee that this will fix the dump/restore issue (well
the dump might load but say the 30000 lines of plpgsql using dynamic SQL
will still be broken). Imho SQL is code so you need to threat it that way...
This is actually one of the smaller issues that can happen when using an
older dump against a new backend and given that we make no promise that
this is supported at all I don't think we should pretend we do for a
specific issue and in fact only a specific subset of that particular issue.
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
