Kenneth Marshall wrote:
On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Minimal really fails to convey the point here IMHO. How about
something like
Andrew Dunstan wrote:
Kenneth Marshall wrote:
On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Minimal really fails to convey the point here IMHO. How about
Andrew Dunstan escribió:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, suppress_redundant_updates_trigger: must be called as
trigger);
Shouldn't these all be ereport()?
--
Alvaro Herrera
Alvaro Herrera wrote:
Andrew Dunstan escribió:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, suppress_redundant_updates_trigger: must be called as
trigger);
Shouldn't these all be ereport()?
Good point.
I'll fix
On Wed, Oct 29, 2008 at 03:48:09PM -0400, Andrew Dunstan wrote:
+ /* make sure it's called as a trigger */
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, suppress_redundant_updates_trigger: must be called
as trigger);
Shouldn't these all be ereport()?
Good point.
I'll
David Fetter wrote:
Maybe we should fix our C sample trigger, from which this was taken.
Yes :)
Does the attached have the right error code?
-elog(ERROR, trigf: not called by trigger manager);
+ereport(ERROR,
+(error(TRIGGERED_DATA_CHANGE_VIOLATION),
+
Andrew Dunstan wrote:
David Fetter wrote:
Maybe we should fix our C sample trigger, from which this was taken.
Yes :)
Does the attached have the right error code?
-elog(ERROR, trigf: not called by trigger manager);
+ereport(ERROR,
+
Andrew Dunstan [EMAIL PROTECTED] writes:
Not sure that's appropriate, but I can't see anything else that is
very appropriate either.
The plpgsql code uses errcode(ERRCODE_FEATURE_NOT_SUPPORTED) for this
situation, so I guess we should be consistent with that.
Andrew Dunstan [EMAIL PROTECTED] writes:
I think I like this best of all the suggestions -
suppress_redundant_updates_trigger() is what I have now.
If there's no further discussion, I'll go ahead and commit this in a day
or two.
The documentation seems a bit lacking: it gives neither a
On Oct 22, 2008, at 1:43 PM, Andrew Dunstan wrote:
+ if (!CALLED_AS_TRIGGER(fcinfo))
+ elog(ERROR, min_update_trigger: not called by trigger
manager);
The error I get in 8.2 when calling a trigger function directly is:
ERROR: trigger functions may only be called as triggers
To
Andrew Dunstan wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
In that case, why not put the trigger in core so people can use it
easily?
One advantage of making it a contrib module is that discussing how/when
to use it would fit more easily into the structure of
Andrew Dunstan [EMAIL PROTECTED] wrote:
Here is a patch that does it that way, along with docs
s/mare/more/
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner wrote:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Here is a patch that does it that way, along with docs
s/mare/more/
Thanks. fixed in my tree..
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Wed, 2008-10-22 at 14:43 -0400, Andrew Dunstan wrote:
There seems to be a preponderance of opinion for doing this as a
builtin. Here is a patch that does it that way, along with docs and
regression test.
In your example you use an underscore as the first character. The way
you have
Simon Riggs [EMAIL PROTECTED] writes:
Can we call the function minimal_update_trigger, rather than min_...
Minimal really fails to convey the point here IMHO. How about
something like suppress_no_op_updates_trigger?
regards, tom lane
--
Sent via pgsql-hackers mailing
Simon Riggs wrote:
On Wed, 2008-10-22 at 14:43 -0400, Andrew Dunstan wrote:
There seems to be a preponderance of opinion for doing this as a
builtin. Here is a patch that does it that way, along with docs and
regression test.
In your example you use an underscore as the first
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Can we call the function minimal_update_trigger, rather than min_...
Minimal really fails to convey the point here IMHO. How about
something like suppress_no_op_updates_trigger?
+1.
On Wed, 2008-10-22 at 17:24 -0400, Robert Haas wrote:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Can we call the function minimal_update_trigger, rather than min_...
Minimal really fails to convey the point here IMHO. How
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Minimal really fails to convey the point here IMHO. How about
something like suppress_no_op_updates_trigger?
I think it means something to us, but no op is a very technical phrase
that
On Wed, Oct 22, 2008 at 06:05:26PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED] wrote:
Minimal really fails to convey the point here IMHO. How about
something like suppress_no_op_updates_trigger?
I think it
Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 3:24 PM, Tom Lane [EMAIL PROTECTED]
wrote:
How about
something like suppress_no_op_updates_trigger?
I think it means something to us, but no op is a very technical
phrase
that probably doesn't travel very well. Not everybody
How about one of these?:
suppress_same_value_updates_trigger
suppress_no_change_updates_trigger
suppress_no_effect_updates_trigger
I like the first one. A trigger firing would be an effect, and
possibly a change, but same value seems very clear.
...Robert
--
Sent via pgsql-hackers
On 20 okt 2008, at 16.51, Andrew Dunstan [EMAIL PROTECTED] wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK. Where would be a good place to put the code? Maybe a new file
src/backend/utils/adt/trigger_utils.c ?
I
On Tue, Oct 21, 2008 at 03:34:04PM +0200, Magnus Hagander wrote:
On 20 okt 2008, at 16.51, Andrew Dunstan [EMAIL PROTECTED] wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK. Where would be a good place to put the code? Maybe a
On Tue, Oct 21, 2008 at 9:34 AM, Magnus Hagander [EMAIL PROTECTED] wrote:
On 20 okt 2008, at 16.51, Andrew Dunstan [EMAIL PROTECTED] wrote:
No, it's not just a hack. It's very close to what we'd probably do if we
built the facility right into the language, although it does involve the
Magnus Hagander [EMAIL PROTECTED] writes:
In that case, why not put the trigger in core so people can use it
easily?
One advantage of making it a contrib module is that discussing how/when
to use it would fit more easily into the structure of the
documentation. There is no place in our docs
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
In that case, why not put the trigger in core so people can use it
easily?
One advantage of making it a contrib module is that discussing how/when
to use it would fit more easily into the structure of the
documentation.
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK. Where would be a good place to put the code? Maybe a new file
src/backend/utils/adt/trigger_utils.c ?
I thought the plan was to make it a contrib module.
Well, previous
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK. Where would be a good place to put the code? Maybe a new file
src/backend/utils/adt/trigger_utils.c ?
I thought the plan was to make it a contrib module.
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce,
did you ever look at completing this?
No, it is still in my email box unaddressed. Feel free to work on it; I
doubt I can do it for 8.4.
OK. Where would be a good place to put the code? Maybe a new file
Andrew Dunstan [EMAIL PROTECTED] writes:
OK. Where would be a good place to put the code? Maybe a new file
src/backend/utils/adt/trigger_utils.c ?
I thought the plan was to make it a contrib module.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK. Where would be a good place to put the code? Maybe a new file
src/backend/utils/adt/trigger_utils.c ?
I thought the plan was to make it a contrib module.
Well, previous discussion did mention
Andrew Dunstan wrote:
Bruce,
did you ever look at completing this?
No, it is still in my email box unaddressed. Feel free to work on it; I
doubt I can do it for 8.4.
---
cheers
andrew
Andrew Dunstan wrote:
Bruce,
did you ever look at completing this?
cheers
andrew
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Right. In fact, I already had that part in fact - see
http://people.planetpostgresql.org/andrew/index.php?/archives/22-Minimal-Update-Trigger.html
What I was
Is there a version of this patch ready for application?
---
Gurjeet Singh wrote:
On Tue, Mar 18, 2008 at 7:46 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Gurjeet Singh wrote:
On Fri, Mar 7, 2008 at 9:40
Not that I know of. I never saw Gurjeet's completed code.
cheers
andrew
Bruce Momjian wrote:
Is there a version of this patch ready for application?
---
Gurjeet Singh wrote:
On Tue, Mar 18, 2008 at 7:46 PM, Andrew
Andrew Dunstan wrote:
Not that I know of. I never saw Gurjeet's completed code.
This is Gurjeet's code, but it is not complete.
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00668.php
---
cheers
Right. In fact, I already had that part in fact - see
http://people.planetpostgresql.org/andrew/index.php?/archives/22-Minimal-Update-Trigger.html
What I was waiting for was the part where it gets put in the catalog,
documented, etc.
cheers
andrew
Bruce Momjian wrote:
Andrew Dunstan
Andrew Dunstan wrote:
Right. In fact, I already had that part in fact - see
http://people.planetpostgresql.org/andrew/index.php?/archives/22-Minimal-Update-Trigger.html
What I was waiting for was the part where it gets put in the catalog,
documented, etc.
I can probably do that part.
Bruce Momjian wrote:
Andrew Dunstan wrote:
Right. In fact, I already had that part in fact - see
http://people.planetpostgresql.org/andrew/index.php?/archives/22-Minimal-Update-Trigger.html
What I was waiting for was the part where it gets put in the catalog,
documented, etc.
I
On Fri, Mar 7, 2008 at 9:40 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I assume don't want a TODO for this? (Suppress UPDATE no changed
columns)
I am starting to implement this. Do we want to have this trigger function in
the server, or in an external module?
Best regards,
Gurjeet Singh wrote:
On Fri, Mar 7, 2008 at 9:40 PM, Bruce Momjian [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I assume don't want a TODO for this? (Suppress UPDATE no changed
columns)
I am starting to implement this. Do we want to have this trigger
function in the
On Tue, Mar 18, 2008 at 7:46 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Gurjeet Singh wrote:
On Fri, Mar 7, 2008 at 9:40 PM, Bruce Momjian [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I assume don't want a TODO for this? (Suppress UPDATE no changed
columns)
I assume don't want a TODO for this? (Suppress UPDATE no changed
columns)
---
Andrew Dunstan wrote:
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
What would be the disadvantages of always doing
On Tue, Feb 19, 2008 at 09:32:30PM -0500, Andrew Dunstan wrote:
As discussed a little while back, I would like to add a generic
trigger function which will force an update to skip if the new and
old tuples are identical.
This one has lots of use cases. Did the earlier discussion settle on
David Fetter wrote:
On Tue, Feb 19, 2008 at 09:32:30PM -0500, Andrew Dunstan wrote:
As discussed a little while back, I would like to add a generic
trigger function which will force an update to skip if the new and
old tuples are identical.
This one has lots of use cases. Did the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, you could write the trigger in C and it'd work for any table.
I think it could be as simple as a memcmp of the tuples' data areas,
since we now require padding bytes to be 0 ...
Something like
Andrew Dunstan [EMAIL PROTECTED] writes:
How does this look?
if (newtuple-t_len == oldtuple-t_len
newtuple-t_data-t_hoff == oldtuple-t_data-t_hoff
HeapTupleHeaderGetNatts(newtuple) ==
HeapTupleHeaderGetNatts(oldtuple)
(newtuple-t_data-t_infomask
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
How does this look?
if (newtuple-t_len == oldtuple-t_len
newtuple-t_data-t_hoff == oldtuple-t_data-t_hoff
HeapTupleHeaderGetNatts(newtuple) == HeapTupleHeaderGetNatts(oldtuple)
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
How does this look?
if (newtuple-t_len == oldtuple-t_len
newtuple-t_data-t_hoff == oldtuple-t_data-t_hoff
HeapTupleHeaderGetNatts(newtuple) ==
HeapTupleHeaderGetNatts(oldtuple)
On Nov 2, 2007, at 10:49 AM, Andrew Dunstan wrote:
update tname set foo = bar ... where foo is null or foo bar ...
FYI, you should be able to do WHERE foo IS DISTINCT FROM bar instead.
--
Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED]
Give your computer some brain candy!
Decibel! wrote:
On Nov 2, 2007, at 10:49 AM, Andrew Dunstan wrote:
update tname set foo = bar ... where foo is null or foo bar ...
FYI, you should be able to do WHERE foo IS DISTINCT FROM bar instead.
True, that's a bit nicer. It's still more than somewhat ugly and fragile
if there a
On Nov 8, 2007, at 10:46 , Andrew Dunstan wrote:
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
What would be the disadvantages of always doing this, i.e., just
making this part of the normal update path in the backend?
(1) cycles wasted to no purpose in the vast
On Nov 2, 2007, at 13:44 , Andrew Dunstan wrote:
Ah. Good. Thanks, that's the piece I was missing.
What would be the disadvantages of always doing this, i.e., just
making this part of the normal update path in the backend? I'd think
it should save on unnecessarily dead tuples as well.
Michael Glaesemann [EMAIL PROTECTED] writes:
What would be the disadvantages of always doing this, i.e., just
making this part of the normal update path in the backend?
(1) cycles wasted to no purpose in the vast majority of cases.
(2) visibly inconsistent behavior for apps that pay
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
What would be the disadvantages of always doing this, i.e., just
making this part of the normal update path in the backend?
(1) cycles wasted to no purpose in the vast majority of cases.
(2) visibly inconsistent behavior
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
A BEFORE UPDATE trigger would be better, and probably hardly more
expensive than a wired-in facility (especially if you were willing to
write it in C).
Yes. I also prefer the trigger idea to a rule
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, you could write the trigger in C and it'd work for any table.
I think it could be as simple as a memcmp of the tuples' data areas,
since we now require padding bytes to be 0 ...
Something like this fragment?
newtuple =
David Fetter [EMAIL PROTECTED] writes:
On Fri, Nov 02, 2007 at 11:49:38AM -0400, Andrew Dunstan wrote:
At the moment I have to write things like:
update tname set foo = bar ... where foo is null or foo bar
One way I've done this is make RULEs which basically drop non-updating
UPDATEs on
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Fri, Nov 02, 2007 at 11:49:38AM -0400, Andrew Dunstan wrote:
At the moment I have to write things like:
update tname set foo = bar ... where foo is null or foo bar
One way I've done this is make RULEs which
On Fri, Nov 02, 2007 at 11:49:38AM -0400, Andrew Dunstan wrote:
For some time I have been working on removing some inefficiencies
from a large DW-type app. This app does a large daily batch update,
and this is what is the major bottleneck. One of the things I have
been doing is to remove
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
A BEFORE UPDATE trigger would be better, and probably hardly more
expensive than a wired-in facility (especially if you were willing to
write it in C).
Yes. I also prefer the trigger idea to a rule
62 matches
Mail list logo
