Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...

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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073