Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
От | Peter Eisentraut |
---|---|
Тема | Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ... |
Дата | |
Msg-id | Pine.LNX.4.44.0310051619000.2745-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: