Peter Eisentraut pete...@gmx.net 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
Tom Lane t...@sss.pgh.pa.us 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 ...
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 itagaki.takah...@oss.ntt.co.jp wrote:
Ok, the attached patch implements standard-compliant version of
column trigger.
Here is an updated version
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
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:
2009/10/7 Peter Eisentraut pete...@gmx.net:
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
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, and
Tom Lane t...@sss.pgh.pa.us 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.
Peter Eisentraut pete...@gmx.net 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Peter Eisentraut pete...@gmx.net 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
On Thu, 2009-10-01 at 10:40 +0900, Itagaki Takahiro wrote:
Peter Eisentraut pete...@gmx.net 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
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
Peter Eisentraut pete...@gmx.net 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:
Peter Eisentraut pete...@gmx.net 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
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 standard:
David Fetter da...@fetter.org 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
On Sep 8, 2009, at 7:38 AM, Kevin Grittner wrote:
David Fetter da...@fetter.org 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
On Mon, Sep 7, 2009 at 6:53 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Peter Eisentraut pete...@gmx.net 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
Kevin Grittner kevin.gritt...@wicourts.gov 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:
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:
triggered action ::=
[ FOREACH { ROW | STATEMENT } ]
[ WHENleft
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
to
Peter Eisentraut pete...@gmx.net 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
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 TRIGGER
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
Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
Tom Lane t...@sss.pgh.pa.us 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
KaiGai Kohei kai...@ak.jp.nec.com 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
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
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut pete...@gmx.net 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
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut pete...@gmx.net 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
On Thu, Sep 3, 2009 at 9:51 AM, Peter Eisentrautpete...@gmx.net wrote:
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut pete...@gmx.net wrote:
The SQL standard specifies that a trigger is fired if the column is
mentioned in the UPDATE
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 cases
Robert Haas robertmh...@gmail.com 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
Hi,
Robert Haas robertmh...@gmail.com 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
Robert Haas wrote:
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp 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
On Thu, Sep 3, 2009 at 10:37 AM, Peter Eisentrautpete...@gmx.net 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
On Thu, 3 Sep 2009, Robert Haas wrote:
On Thu, Sep 3, 2009 at 9:51 AM, Peter Eisentrautpete...@gmx.net wrote:
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut pete...@gmx.net wrote:
The SQL standard specifies that a trigger is fired if 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 Herrera
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
On Thu, Sep 3, 2009 at 2:16 PM, Peter Eisentrautpete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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?
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
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!
I
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp 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();
Robert Haas robertmh...@gmail.com 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;
David Fetter da...@fetter.org 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 =
Itagaki Takahiro wrote:
David Fetter da...@fetter.org 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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.
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
51 matches
Mail list logo
