Re: Feedback on writing extensible modules - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Feedback on writing extensible modules
Date
Msg-id 45633DE2-1E06-454C-AAE7-75325E852154@hi-media.com
Whole thread Raw
In response to Re: Feedback on writing extensible modules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Feedback on writing extensible modules  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: check for missing tablespaces?
Next
From: Tom Lane
Date:
Subject: Re: Dtrace probes documentation