Tom Lane writes:
> I think that issues like these are likely to arise for other sorts of
> checks than those on embedded SQL code. For example, it probably
> wouldn't be unreasonable for a validator for brand-X-language to try to
> check the existence of referenced functions, even if those functions are
> called from code that doesn't look much like SQL.
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.
--
Peter Eisentraut peter_e@gmx.net
