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