Tom Lane wrote:
> Applied with assorted corrections, mostly cosmetic but not entirely.
> One thing you really should have caught was updating
> copyfuncs/equalfuncs for the parsenode field addition.
> Next time, try grepping for every reference to a struct type you
> change ...
Thanks for the f
Itagaki Takahiro writes:
> column-trigger_20091014.patch is a full patch to the HEAD.
Applied with assorted corrections, mostly cosmetic but not entirely.
One thing you really should have caught was updating
copyfuncs/equalfuncs for the parsenode field addition.
Next time, try grepping for every
Peter Eisentraut writes:
> Btw., I might not get a chance to commit this within the next 48 hours.
> If someone else wants to, go ahead.
I will take it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Sat, 2009-10-10 at 00:04 +0300, Peter Eisentraut wrote:
> On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
> > Itagaki Takahiro wrote:
> >
> > > Ok, the attached patch implements standard-compliant version of
> > > column trigger.
> >
> > Here is an updated version of column-level t
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
> Itagaki Takahiro wrote:
>
> > Ok, the attached patch implements standard-compliant version of
> > column trigger.
>
> Here is an updated version of column-level trigger patch.
> I forgot to adjust pg_get_triggerdef() in the previous ve
On Thu, 2009-10-08 at 08:57 +1100, Brendan Jurd wrote:
> What's the current status of this patch in the commitfest process?
I'm working on it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
2009/10/7 Peter Eisentraut :
> On Sun, 2009-10-04 at 22:07 -0400, Tom Lane wrote:
>> In short: while I haven't looked at the patch, I think Peter may be
>> steering you in the wrong direction.
>>
>> In cases where you do have related functions, I suggest having
>> SQL-callable V1 functions that abs
On Sun, 2009-10-04 at 22:07 -0400, Tom Lane wrote:
> In short: while I haven't looked at the patch, I think Peter may be
> steering you in the wrong direction.
>
> In cases where you do have related functions, I suggest having
> SQL-callable V1 functions that absorb their arguments in this
> style
Tom Lane writes:
> In cases where you do have related functions, I suggest having
> SQL-callable V1 functions that absorb their arguments in this
> style, and then have them call a common subroutine that's a plain
> C function.
Unless you have high performance requirements, IME. Avoiding the SQL
Itagaki Takahiro writes:
> Peter Eisentraut wrote:
>> OK, but what you can do is point both variants to the same C function
>> and check with PG_NARGS() with how many arguments you were called. That
>> would save some of the indirections.
> The regressiontest 'opr_sanity' failed if do so. Shoul
Peter Eisentraut wrote:
> OK, but what you can do is point both variants to the same C function
> and check with PG_NARGS() with how many arguments you were called. That
> would save some of the indirections.
The regressiontest 'opr_sanity' failed if do so. Should we remove this
check only for
On Thu, 2009-10-01 at 10:40 +0900, Itagaki Takahiro wrote:
> > Peter Eisentraut wrote:
> > > If you want a "pretty" option on pg_get_triggerdef(), you could nowadays
> > > also implement that via a parameter default value instead of a second
> > > function.
> >
> > OK, I'll rewrite it to use defa
> Peter Eisentraut wrote:
> > If you want a "pretty" option on pg_get_triggerdef(), you could nowadays
> > also implement that via a parameter default value instead of a second
> > function.
>
> OK, I'll rewrite it to use default parameter.
I tried to remove pg_get_triggerdef_ext() and add a se
Peter Eisentraut wrote:
> What is the purpose of the new pg_get_triggerdef() variant? OK, the
> parameter name "pretty_bool" gives a hint, but what does this have to do
> with column triggers? Maybe you could try to explain this in more
> detail. Ideally split the patch into two: one that dea
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
> Itagaki Takahiro wrote:
>
> > Ok, the attached patch implements standard-compliant version of
> > column trigger.
>
> Here is an updated version of column-level trigger patch.
> I forgot to adjust pg_get_triggerdef() in the previous ve
On Tue, Sep 08, 2009 at 06:28:36PM -0700, James Pye wrote:
> On Sep 8, 2009, at 5:33 PM, Itagaki Takahiro wrote:
>> WHEN clause in other times [1][2][3]. (All of them use "WHEN" for
>> the syntax; that's why I proposed "WHEN" but not "WHERE".)
>
> Well, looks like WHEN is, or is going to be standar
On Sep 8, 2009, at 5:33 PM, Itagaki Takahiro wrote:
WHEN clause in other times [1][2][3]. (All of them use "WHEN" for the
syntax; that's why I proposed "WHEN" but not "WHERE".)
Well, looks like WHEN is, or is going to be standard:
::=
[ FOREACH { ROW | STATEMENT } ]
[ WHEN ]
(page 653
"Kevin Grittner" wrote:
> How much does that buy you versus including this at the start of
> trigger_func:
One of the benefits is that it could handle tuple modifications
by another trigger, that is discussed here:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00161.php
| 2. Reche
On Mon, Sep 7, 2009 at 6:53 AM, Itagaki
Takahiro wrote:
>
> Peter Eisentraut wrote:
>
>> Therefore, it cannot be completely unexpected if column triggers are
>> called even if the column was not actually changed in a semantically
>> significant way.
>
> Ok, the attached patch implements standard-c
On Sep 8, 2009, at 7:38 AM, Kevin Grittner wrote:
David Fetter wrote:
CREATE TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW
WHEN (NEW.col IS DISTINCT FROM OLD.col)
EXECUTE PROCEDURE trigger_func();
How much does that buy you versus including this at the start of
trigger_func:
On
David Fetter wrote:
> CREATE TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW
> WHEN (NEW.col IS DISTINCT FROM OLD.col)
> EXECUTE PROCEDURE trigger_func();
How much does that buy you versus including this at the start of
trigger_func:
IF (NEW.col IS NOT DISTINCT FROM OLD.col) THEN
On Mon, Sep 07, 2009 at 07:53:01PM +0900, Itagaki Takahiro wrote:
> However, to be honest, I think standard-compliant column trigger is
> useless... I'm thinking additional extension for triggers -- if we
> want to check modifications of actual values, it could be defined
> as:
>
> CREATE TRIG
Peter Eisentraut wrote:
> Therefore, it cannot be completely unexpected if column triggers are
> called even if the column was not actually changed in a semantically
> significant way.
Ok, the attached patch implements standard-compliant version of
column trigger.
Retrieving modified columns i
On Mon, 2009-09-07 at 11:20 +0900, Itagaki Takahiro wrote:
> We are discussing how to determine modified columns
> (UPDATE-target vs. changes of actual values), but in the patch
> I used value-based checking. The reasons are:
If you implement a new feature using syntax from the standard, you have
Here is a updated version of column-trigger patch.
Changes from the previous patch:
* Add dependency of columns with recordDependencyOn().
Regression tests are also adjusted.
* Recheck columns if NEW values are modified, but each trigger
will be firec only one per row.
Peter Eisentra
Peter Eisentraut wrote:
> The SQL standard specifies that a trigger is fired if the column is
> mentioned in the UPDATE statement, independent of whether the value is
> actually changed through the update.
Hmmm, what does the SQL standard say about modification of NEW values?
Should we fire col
Peter Eisentraut writes:
> On tor, 2009-09-03 at 11:19 -0400, Robert Haas wrote:
>> Sure, but I don't think it makes a lot of sense to spend a lot of time
>> implementing the standard behavior unless someone can provide a
>> plausible use case.
> One use case is porting Oracle applications. I se
On Thu, Sep 3, 2009 at 2:16 PM, Peter Eisentraut wrote:
> On tor, 2009-09-03 at 11:19 -0400, Robert Haas wrote:
>> Sure, but I don't think it makes a lot of sense to spend a lot of time
>> implementing the standard behavior unless someone can provide a
>> plausible use case.
>
> One use case is por
On tor, 2009-09-03 at 11:19 -0400, Robert Haas wrote:
> Sure, but I don't think it makes a lot of sense to spend a lot of time
> implementing the standard behavior unless someone can provide a
> plausible use case.
One use case is porting Oracle applications. I see a lot of that used
there. The
iog...@free.fr escribió:
> A simple use case would be to update a timestamp column with
> CURRENT_TIMESTAMP as instance.
No, because you want to update the timestamp in all cases, whatever
columns the update actually updates.
--
Alvaro Herrerahttp://www.CommandPr
On Thu, 3 Sep 2009, Robert Haas wrote:
On Thu, Sep 3, 2009 at 9:51 AM, Peter Eisentraut wrote:
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
The SQL standard specifies that a trigger is fired if the column is
mentioned in the UPDATE
On Thu, Sep 3, 2009 at 10:37 AM, Peter Eisentraut wrote:
> On Thu, 2009-09-03 at 10:24 -0400, Robert Haas wrote:
>> If TRIGGER ON UPDATE OF foo_id means whether the value actually
>> changed, then I can skip the check. If TRIGGER ON UPDATE OF foo_id
>> means whether the column was present in the u
Robert Haas wrote:
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiro wrote:
Here is a patch to implement "Support triggers on columns" in our ToDo list.
The syntax is:
CREATE TRIGGER name
BEFORE UPDATE OF col1, col12, ...
ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
I con
Hi,
Robert Haas writes:
> By the way, I completely agree that it would be useful to have a way
> to suppress triggers from firing when no columns were actually
> modified.
http://www.postgresql.org/docs/8.4/static/functions-trigger.html
Currently PostgreSQL provides one built in trigger f
Robert Haas wrote:
> It also seems to me logically inconsistent that we would expose this
> information via the CREATE TRIGGER interface but not to the trigger
> function itself. From within the function, you can compare NEW and
> OLD, but you get no visibility into which columns were actually
On Thu, 2009-09-03 at 10:24 -0400, Robert Haas wrote:
> If TRIGGER ON UPDATE OF foo_id means whether the value actually
> changed, then I can skip the check. If TRIGGER ON UPDATE OF foo_id
> means whether the column was present in the update list, then it
> doesn't. Perhaps there are some use cas
On Thu, Sep 3, 2009 at 9:51 AM, Peter Eisentraut wrote:
> On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
>> On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
>> > The SQL standard specifies that a trigger is fired if the column is
>> > mentioned in the UPDATE statement, independent of whe
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
> On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
> > The SQL standard specifies that a trigger is fired if the column is
> > mentioned in the UPDATE statement, independent of whether the value is
> > actually changed through the update.
>
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
On Thu, 2009-09-03 at 16:25 +0900, Itagaki Takahiro wrote:
I'd like to check conditions by comparing actual values but not
a target of UPDATE statement because I think almost user expects
the former behavior. Unmodified UPDATE-targets are com
On Thu, 2009-09-03 at 16:25 +0900, Itagaki Takahiro wrote:
> I'd like to check conditions by comparing actual values but not
> a target of UPDATE statement because I think almost user expects
> the former behavior. Unmodified UPDATE-targets are common case
> if we use a framework that generates SQL
KaiGai Kohei wrote:
> Itagaki-san, isn't it more suitable to check rte->modifiedCols
> than heap_tuple_attr_equals()? Although, this information is
> not delivered to executor...
I'd like to check conditions by comparing actual values but not
a target of UPDATE statement because I think almost
Tom Lane wrote:
> exactly how, and when, are you determining whether a column has
> been "modified"? I can't count the number of times somebody
> has proposed simplistic and incorrect solutions to that.
> Usually they forget about BEFORE triggers changing the row.
There are some approaches:
Tom Lane wrote:
> Itagaki Takahiro writes:
>> Sure, and I found there might be difference between "UPDATE" and
>> "UPDATE OF {all-columns}" triggers. UPDATE trigger is always fired
>> when a row is updated even if none of the columns are actually
>> modified, but UPDATE OF {all-columns} trigger is
Itagaki Takahiro writes:
> Sure, and I found there might be difference between "UPDATE" and
> "UPDATE OF {all-columns}" triggers. UPDATE trigger is always fired
> when a row is updated even if none of the columns are actually
> modified, but UPDATE OF {all-columns} trigger is fired only when
> at
Itagaki Takahiro writes:
> But how? First, I tried to use existing dependency mechanism:
> ObjectAddress referenced;
> referenced.classId = AttributeRelationId;
> referenced.objectId = {relid};
> referenced.objectSubId = {attnum};
This is just wrong. The correct representation o
Itagaki Takahiro wrote:
>
> David Fetter wrote:
>
> > > It's still arguable that we should add dependencies from column
> > > triggers to referenced columns.
> >
> > +1 for adding the dependencies.
>
> But how? First, I tried to use existing dependency mechanism:
>
> ObjectAddress referen
David Fetter wrote:
> > It's still arguable that we should add dependencies from column
> > triggers to referenced columns.
>
> +1 for adding the dependencies.
But how? First, I tried to use existing dependency mechanism:
ObjectAddress referenced;
referenced.classId = AttributeRelatio
Robert Haas wrote:
> Wow, so I wouldn't have to do this any more?
>
> IF (TG_OP = 'UPDATE') THEN
> IF (OLD.foo IS NOT DISTINCT FROM NEW.foo AND OLD.bar IS NOT
> DISTINCT FROM NEW.bar
> AND OLD.baz IS NOT DISTINCT FROM NEW.baz) THEN
> RETURN NULL;
> END IF;
> END IF;
Su
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiro wrote:
> Here is a patch to implement "Support triggers on columns" in our ToDo list.
>
> The syntax is:
> CREATE TRIGGER name
> BEFORE UPDATE OF col1, col12, ...
> ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
>
> I consulted the pr
On Thu, Sep 03, 2009 at 10:52:09AM +0900, Itagaki Takahiro wrote:
> Here is a patch to implement "Support triggers on columns" in our ToDo list.
>
> The syntax is:
> CREATE TRIGGER name
> BEFORE UPDATE OF col1, col12, ...
> ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
Kudos!
Here is a patch to implement "Support triggers on columns" in our ToDo list.
The syntax is:
CREATE TRIGGER name
BEFORE UPDATE OF col1, col12, ...
ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
I consulted the previous work following:
Column-level triggers (From: Greg Sabino
51 matches
Mail list logo
