Peter Eisentraut wrote: > Given that new languages don't tend to appear out of the blue, I think > it's reasonable to design the feature considering the languages currently > available. We have sql, plpgsql, pltcl, plpython, plperl, plruby, plsh, > pljava, maybe something Scheme-based. None of these languages except the > first two have anything to gain, but everything to lose, if they were > asked not to check the function body during a dump restore. So do you > have anything more particular in mind? > > > Would you like it better if the switch were called > > do_all_the_right_things_for_pg_dump? (That name is a bit facetious, but > > in terms of long-term behavior that's pretty much what I'm after.) > > Would that include altering all sorts of other behaviors, beyond the issue > of function bodies, to facilitate restoring dumps? That might not be the > worst of ideas, but I'd rather see us improving pg_dump and keep the > relaxed behavior constrained to very well defined areas.
Once we put a GUC value in a dump, we have to keep that parameter valid almost forever. I think a general restore GUC setting will be much more valuable in the future. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
