Tom Lane wrote:
> > [ TRIGGER WHEN patch ]
> Applied with assorted revisions. AFAICT the system column issue is only
> a problem for NEW references in BEFORE triggers --- those columns do
> read correctly in OLD, and all the time in AFTER triggers. I revised
> the parsing logic to enforce that
Itagaki Takahiro writes:
> [ TRIGGER WHEN patch ]
Applied with assorted revisions. AFAICT the system column issue is only
a problem for NEW references in BEFORE triggers --- those columns do
read correctly in OLD, and all the time in AFTER triggers. I revised
the parsing logic to enforce that.
Itagaki Takahiro writes:
> [ TRIGGER WHEN patch ]
I'm starting to work this over now, and I've found one rather serious
omission: FreeTriggerDesc doesn't free the expression tree. This means
that trigger WHEN clauses will leak memory in CacheMemoryContext any
time we do a relcache flush on the r
Itagaki-san,
I don't have any more comments in this patch, so I hope it to be reviewed
by committers then upstreamed.
Thanks for your good jobs.
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>> In addition, I could find a few matters.
>> * TOAST may be necessary for pg_trigger?
>
> I added
Itagaki-san, I checked the latest patch.
It seems to me the patch getting improved from the prior version.
We are next to the commiter review phase.
But I could find a few matters. :-(
Please see the following comments, and fix it before sending it
to commiters.
> I fixed the bug and two other b
KaiGai Kohei wrote:
> Itagaki-san, I also think your example usage is enough valueable.
> However, Oracle does not have the feature apparently, although the
> purpose of this patch is to provide a compatible feature, IIRC.
>
> I don't have any preference on either of them.
> If you make a decis
Albe Laurenz wrote:
> SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
> 2 BEGIN
> 3 END;
> 4 /
> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
> *
> ERROR at line 1:
> ORA-04077: WHEN clause cannot be used wit
KaiGai Kohei wrote:
> I'm uncertain how Oracle handles the condition on the statement
> triggers. But it seems to me WHEN clause on the statement triggers
> are nonsense.
SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
2 BEGIN
3 END;
4 /
CREATE TRIGGER dummy BEFORE DELET
KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
>> Here is a updated TRIGGER with WHEN cluase patch.
>> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
>
> I would like to volunteer for reviewing the patch in RR-stage.
> It seems to me an interesting feature.
It seems to me you
Itagaki Takahiro wrote:
> Here is a updated TRIGGER with WHEN cluase patch.
> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
I would like to volunteer for reviewing the patch in RR-stage.
It seems to me an interesting feature.
--
OSS Platform Development Division, NEC
KaiGai
Stephan Szabo writes:
> On Fri, 16 Oct 2009, Tom Lane wrote:
>> I note BTW that we have some ad-hoc logic already that arranges to
>> suppress queuing of AFTER events for FK triggers, if the FK column
>> value has not changed. It might be interesting to look at whether
>> that hack could be unifi
On Fri, 16 Oct 2009, Tom Lane wrote:
> I note BTW that we have some ad-hoc logic already that arranges to
> suppress queuing of AFTER events for FK triggers, if the FK column
> value has not changed. It might be interesting to look at whether
> that hack could be unified with the user-accessible
Simon Riggs writes:
> If the function is idempotent then we can also optimise away multiple
> calls by checking whether a similar call is already queued.
But how would we know that? It seems orthogonal to this patch,
anyway.
regards, tom lane
--
Sent via pgsql-hackers
On Fri, 2009-10-16 at 10:02 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> >> * It will reduce size of in-memory pending trigger list (for large
> >> statements)
>
> > But this won't be the outcome when it's implemented the way it is
Peter Eisentraut writes:
> On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
>> * It will reduce size of in-memory pending trigger list (for large
>> statements)
> But this won't be the outcome when it's implemented the way it is being
> proposed, which checks the where clause just before exe
On Fri, 2009-10-16 at 14:39 +0300, Peter Eisentraut wrote:
> On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> > * It will reduce size of in-memory pending trigger list (for large
> > statements)
>
> But this won't be the outcome when it's implemented the way it is being
> proposed, which ch
On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> * It will reduce size of in-memory pending trigger list (for large
> statements)
But this won't be the outcome when it's implemented the way it is being
proposed, which checks the where clause just before executing the
trigger function.
--
On Fri, 2009-10-16 at 10:14 +0900, Itagaki Takahiro wrote:
> Tom Lane wrote:
>
> > Itagaki Takahiro writes:
> > > I think there is a benefit to provide WHEN cluase at least
> > > for compatibility with other DBMSs, even through we can move
> > > the expressions into the body of trigger functions
On Thu, 2009-10-15 at 16:54 -0500, Kevin Grittner wrote:
> Dimitri Fontaine wrote:
>
> > It's pretty often the case (IME) that calling a trigger is the only
> > point in the session where you fire plpgsql, and that's a visible
> > cost.
>
> Wouldn't a connection pool solve this?
No
--
Simo
Tom Lane wrote:
> Itagaki Takahiro writes:
> > I think there is a benefit to provide WHEN cluase at least
> > for compatibility with other DBMSs, even through we can move
> > the expressions into the body of trigger functions.
>
> This seems to me to be a lot of code to accomplish nothing usef
Dimitri Fontaine wrote:
> It's pretty often the case (IME) that calling a trigger is the only
> point in the session where you fire plpgsql, and that's a visible
> cost.
Wouldn't a connection pool solve this?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Tom Lane writes:
> That argument is based on a completely evidence-free assumption, namely
> that this patch would make your case faster. Executing the WHEN tests
> is hardly going to be zero cost. It's not too hard to postulate cases
> where implementing a filter this way would be *slower* than
Pavel Stehule writes:
> 2009/10/15 Tom Lane :
>> This seems to me to be a lot of code to accomplish nothing useful.
> I disagree. When I analysed speed of some operations, I found some
> unwanted trigger calls should to slow down applications. I am for any
> method, that could to decrease trigger
Itagaki Takahiro writes:
> I think there is a benefit to provide WHEN cluase at least
> for compatibility with other DBMSs, even through we can move
> the expressions into the body of trigger functions.
This seems to me to be a lot of code to accomplish nothing useful.
It will always be the case
2009/10/15 Tom Lane :
> Itagaki Takahiro writes:
>> I think there is a benefit to provide WHEN cluase at least
>> for compatibility with other DBMSs, even through we can move
>> the expressions into the body of trigger functions.
>
> This seems to me to be a lot of code to accomplish nothing usefu
25 matches
Mail list logo
