Re: Feedback on writing extensible modules
От | Dimitri Fontaine |
---|---|
Тема | Re: Feedback on writing extensible modules |
Дата | |
Msg-id | 45633DE2-1E06-454C-AAE7-75325E852154@hi-media.com обсуждение исходный текст |
Ответ на | Re: Feedback on writing extensible modules (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Feedback on writing extensible modules
|
Список | pgsql-hackers |
Hi, First, thank you to have taken the time to see about the case. Le 31 mai 09 à 18:21, Tom Lane a écrit : > The reason this doesn't work is that SPI can only be invoked inside a > transaction, and you're not inside one when a library is being > preloaded. Makes sense. Still crashing with basic naive testing, will report back when I have more time to work on it. > You could maybe make this work by executing your own transaction > to do it, but I really have to wonder if it's a good idea. One > point to think about is that elog(ERROR) still means elog(FATAL) > at this point, so any brokenness in the queries you're trying to > prepare will result in locking all users out of the database. Yeah that's a pretty good foot gun, yet another one. But preprepare.at_init is optional and defaults to off. If you broke it all, you can turn it off again and reload. As for the FATAL, I guess that having preprepare crashing backend creations rather than having your EXECUTE fail and ROLLBACK your transactions is not so much a difference when you need preprepare in the first place... I'll add a note in the documentation to always manually call SELECT prepare_all() at each prepare statements list modification before to turn at_init on, as soon as at_init is possible. Regards, -- dim
В списке pgsql-hackers по дате отправления: