Stephen Frost wrote:
> * Magnus Hagander (magnus@hagander.net) wrote:
>> On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
>> <stefan@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