Обсуждение: Running query without trigger?

Поиск
Список
Период
Сортировка

Running query without trigger?

От
hamann.w@t-online.de
Дата:
Hi,

a table is associated with a trigger for normal use.
An admin (someone with ALTER privilege) can disable tthe trigger, run some bulk update,
and then re-enable it. This means, however, that  normal user activity has to be locked out.

There are two possible scenarios: the bulk update would not cause trigger activity at all,
because of the values and columns involved.
or - the bulk update is followed by another bulk transaction that  is equivalent to trigger
invocations per row.
At least in the first case, running this particular query without triggering the trigger,
but normal activity still going on, would be really great
Is there a way to achieve this?

Regards
Wolfgang Hamann




Re: Running query without trigger?

От
"Charles Clavadetscher"
Дата:
Good morning

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of hamann.w@t-
> online.de
> Sent: Samstag, 9. Juli 2016 08:20
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Running query without trigger?
>
>
> Hi,
>
> a table is associated with a trigger for normal use.
> An admin (someone with ALTER privilege) can disable tthe trigger, run some bulk update, and then re-enable it. This
> means, however, that  normal user activity has to be locked out.
>
> There are two possible scenarios: the bulk update would not cause trigger activity at all, because of the values and
> columns involved.
> or - the bulk update is followed by another bulk transaction that  is equivalent to trigger invocations per row.
> At least in the first case, running this particular query without triggering the trigger, but normal activity still
> going on, would be really great Is there a way to achieve this?

In general it helps better if you provide the version of PostgreSQL that you are using.

If you have a way to identify the bulk update from a record field, e.g. a timestamp or something like this, you may use
WHENto exclude them from firing the trigger. I am not sure if it is possible to use a condition other than using the
fieldsof the old or new record. 

https://www.postgresql.org/docs/current/static/sql-createtrigger.html

Regards
Charles

>
> Regards
> Wolfgang Hamann
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



Re: Running query without trigger?

От
Berend Tober
Дата:
hamann.w@t-online.de wrote:
>
> Hi,
>
> a table is associated with a trigger for normal use.
> An admin (someone with ALTER privilege) can disable tthe trigger, run some bulk update,
> and then re-enable it. This means, however, that  normal user activity has to be locked out.
>
> There are two possible scenarios: the bulk update would not cause trigger activity at all,
> because of the values and columns involved.
> or - the bulk update is followed by another bulk transaction that  is equivalent to trigger
> invocations per row.
> At least in the first case, running this particular query without triggering the trigger,
> but normal activity still going on, would be really great
> Is there a way to achieve this?


For UPDATE events, it is possible to specify a list of columns using this syntax:

UPDATE OF column_name1 [, column_name2 ... ]

The trigger will only fire if at least one of the listed columns is mentioned as a target of the
UPDATE command.


So, if you use that optional syntax, then since as you described it, the columns in your update
statement would not be included in the "OF" list and hence not fire this update trigger. Meanwhile,
normal updates, presumably which did involve columns in the "OF" list, would appropriately fire the
trigger as required.






Re: Running query without trigger?

От
Christian Elmerot
Дата:
On 2016-07-09 08:20, hamann.w@t-online.de wrote:
> Hi,
>
> a table is associated with a trigger for normal use.
> An admin (someone with ALTER privilege) can disable tthe trigger, run some bulk update,
> and then re-enable it. This means, however, that  normal user activity has to be locked out.
>
> There are two possible scenarios: the bulk update would not cause trigger activity at all,
> because of the values and columns involved.
> or - the bulk update is followed by another bulk transaction that  is equivalent to trigger
> invocations per row.
> At least in the first case, running this particular query without triggering the trigger,
> but normal activity still going on, would be really great
> Is there a way to achieve this?
>
> Regards
> Wolfgang Hamann

Well for temporary disabling triggers the easiest is to run:
     SET session_replication_role = replica;
     UPDATE ...
     SET session_replication_role = DEFAULT;

This only affects the current session i.e. you and not any other
sessions which is what you seemed to require. All this assuming you run
a supported version of postgres

Regards,
Christian Elmerot, Systems Engineer One.com


Re: Running query without trigger?

От
hamann.w@t-online.de
Дата:
>> On 2016-07-09 08:20, hamann.w@t-online.de wrote:
>> > Hi,
>> >
>> > a table is associated with a trigger for normal use.
>> > An admin (someone with ALTER privilege) can disable tthe trigger, run some bulk update,
>> > and then re-enable it. This means, however, that  normal user activity has to be locked out.
>> >
>> > There are two possible scenarios: the bulk update would not cause trigger activity at all,
>> > because of the values and columns involved.
>> > or - the bulk update is followed by another bulk transaction that  is equivalent to trigger
>> > invocations per row.
>> > At least in the first case, running this particular query without triggering the trigger,
>> > but normal activity still going on, would be really great
>> > Is there a way to achieve this?
>> >
>> > Regards
>> > Wolfgang Hamann
>>
>> Well for temporary disabling triggers the easiest is to run:
>>      SET session_replication_role = replica;
>>      UPDATE ...
>>      SET session_replication_role = DEFAULT;
>>
>> This only affects the current session i.e. you and not any other
>> sessions which is what you seemed to require. All this assuming you run
>> a supported version of postgres
>>
>> Regards,
>> Christian Elmerot, Systems Engineer One.com
>>
Hello Christian,

thanks for the tip.
Out of the suggestions I got, specifying a list of relevant columns seems to be the best one
for my specific case. I believe your suggestion will be helpful in other - more ad hoc -
situations

Regards
Wolfgang






Re: Running query without trigger?

От
hamann.w@t-online.de
Дата:
>> On 2016-07-09 08:20, hamann.w@t-online.de wrote:
>> > Hi,
>> >
>> > a table is associated with a trigger for normal use.
>> > An admin (someone with ALTER privilege) can disable tthe trigger, run some bulk update,
>> > and then re-enable it. This means, however, that  normal user activity has to be locked out.
>> >
>> > There are two possible scenarios: the bulk update would not cause trigger activity at all,
>> > because of the values and columns involved.
>> > or - the bulk update is followed by another bulk transaction that  is equivalent to trigger
>> > invocations per row.
>> > At least in the first case, running this particular query without triggering the trigger,
>> > but normal activity still going on, would be really great
>> > Is there a way to achieve this?
>> >
>> > Regards
>> > Wolfgang Hamann
>>
>> Well for temporary disabling triggers the easiest is to run:
>>      SET session_replication_role = replica;
>>      UPDATE ...
>>      SET session_replication_role = DEFAULT;
>>
>> This only affects the current session i.e. you and not any other
>> sessions which is what you seemed to require. All this assuming you run
>> a supported version of postgres
>>
>> Regards,
>> Christian Elmerot, Systems Engineer One.com
>>
Hello Christian,

thanks for the tip.
Out of the suggestions I got, specifying a list of relevant columns seems to be the best one
for my specific case. I believe your suggestion will be helpful in other - more ad hoc -
situations

Regards
Wolfgang