Re: Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
Date: 2007-01-25 23:55:46
Message-ID: 14675.1169769346@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> The value definitions of tg_enabled would be

> A fires always
> N fires never
> O fires on transaction origin only
> R fires on replica only

> A new per session GUC variable, restricted to superusers, will define if
> the session is in origin or replica mode.

Are you sure two states are enough?

No particular objection, but now would be the time to think if a boolean
is sufficient.

> Likewise the system catalog pg_rewrite is extended with an attribute
> ev_enabled. It will have the same possible values and a new command,

I assume there'd be no intention of supporting on-the-fly changes of
this setting (ie, you'd set the GUC variable once at session startup
and not change thereafter)? Otherwise you'd have a problem with cached
plans.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2007-01-26 00:25:18 Re: Proposal: Change of pg_trigger.tg_enabled and adding
Previous Message Tom Lane 2007-01-25 23:49:43 Re: Proposal: Commit timestamp