Re: Is drop/restore trigger transactional?

On Tue, Aug 7, 2012 at 3:22 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Tue, Aug 7, 2012 at 2:39 PM, Craig James <cjames(at)emolecules(dot)com> wrote:
>> On Tue, Aug 7, 2012 at 1:45 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>> On Tue, Aug 7, 2012 at 1:15 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>>>
>>>> IF current_user = 'bulk_writer' THEN
>>>> return new;
>>>> END IF;
>>>> <expensive stuff>
>>>
>>> I don't know Craig's case, but often the most expensive of the
>>> "expensive stuff" is the bare fact of firing a trigger in the first
>>> place.
>>
>> My use case is pretty simple: Copy some already-validated user data
>> from one schema to another. Since the trigger has already been
>> applied, we're guaranteed that the data is already in the form we
>> want.
>>
>> For your amusement:
>
> Thanks. That was probably more amusing to me in particular than to most
> pgsql hackers, as I think I've been a victim of your trigger.
>
>
> ...
>>
>> Obviously this is a very expensive trigger, but one that we can drop
>> in a very specific circumstance. But we NEVER want to drop it for
>> everyone. It seems like a very reasonable use-case to me.
>
> And since the query is absolutely expensive, not just expensive
> relative to a no-op, then Merlin's suggestion seems entirely suitable
> for your use-case.

Thanks for the ideas. I think I have something to work with.

Craig James