Re: BUG #5066: plperl issues with perl_destruct() and END blocks
От | Tom Lane |
---|---|
Тема | Re: BUG #5066: plperl issues with perl_destruct() and END blocks |
Дата | |
Msg-id | 7729.1253628804@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5066: plperl issues with perl_destruct() and END blocks (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: BUG #5066: plperl issues with perl_destruct() and END
blocks
Re: BUG #5066: plperl issues with perl_destruct() and END blocks |
Список | pgsql-bugs |
Robert Haas <robertmhaas@gmail.com> writes: > If the changes are simple, as Tim seems to believe, exactly what do we > lose by doing this? It's not simple. There are any number of issues that Tim has not addressed. The most obvious: *his* use case might not require database access in an END block, but that doesn't mean the next complainant won't want it. Another point that comes to mind is shared_preload_libraries: if plperl is loaded once in the postmaster, it seems entirely likely that the same END block would be executed in multiple backends after having been loaded only once. Again, while that might be okay for his particular use-case, it seems horribly dangerous for anything else. (The shared_preload_libraries case also destroys the most obvious implementation path, ie having plperl add an on_proc_exit callback at _PG_init time...) But my basic objection is that a PL is a device for executing code in functions. It has no business being used to cause "action at a distance" outside of those functions. If we go down this path we are going to regret it. regards, tom lane
В списке pgsql-bugs по дате отправления: