I propose that the following should be added to the TODO list:
- expose read-only NEW/OLD rowsets in statement-level triggers that
represent the affected rows.
- Implement a way to enable triggers to check which columns are affected
by the triggering statement.
Regards,
Andreas
-
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Consider this:
> Table with one column that is maintained by a trigger for this rule:
> - Only one row in a group of rows may have a foo-value of "true", all
> others must be "false".
> - If foo=true is inserted/updated, other members of that data group
Andreas Pflug wrote:
> YATS (yet another TODO suggestion):
> provide an official and reliable way to temporarily enable/disable triggers.
> "ALTER TABLE xxx ENABLE/DISABLE TRIGGER ALL/trgName"
>
> We still have that nasty "not presently checked everywhere it should be"
> comment in the doc for pg
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I wonder why you are suggesting workarounds for features that other
databases provide.
The fact that other databases provide 'em doesn't make them good ideas.
In particular, writing a trigger that assumes that only the fields
chang
Andreas Pflug <[EMAIL PROTECTED]> writes:
> - Implement a way to enable triggers to check which columns are affected
> by the triggering statement.
This can already be done by comparing old and new values, no?
I don't have a lot of sympathy for the idea that checking what the
original UPDATE tou
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This can already be done by comparing old and new values, no?
No, this is not the case.
UPDATE foo SET x=x, y=y
is different from
UPDATE foo SET y=y
if triggers maintaining x are involved.
Only f
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This can already be done by comparing old and new values, no?
>>
> No, this is not the case.
> UPDATE foo SET x=x, y=y
> is different from
> UPDATE foo SET y=y
> if triggers maintaining x are involved.
Only for what I would call extr
Bruce Momjian wrote:
Andreas Pflug wrote:
YATS (yet another TODO suggestion):
provide an official and reliable way to temporarily enable/disable triggers.
"ALTER TABLE xxx ENABLE/DISABLE TRIGGER ALL/trgName"
We still have that nasty "not presently checked everywhere it should be"
comment in th
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I wonder why you are suggesting workarounds for features that other
> databases provide.
The fact that other databases provide 'em doesn't make them good ideas.
In particular, writing a trigger that assumes that only the fields
changed by the original U
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Consider this:
Table with one column that is maintained by a trigger for this rule:
- Only one row in a group of rows may have a foo-value of "true", all
others must be "false".
- If foo=true is inserted/updated, other members of that d
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
- Implement a way to enable triggers to check which columns are affected
by the triggering statement.
This can already be done by comparing old and new values, no?
No, this is not the case.
UPDATE foo SET x=x, y=y
is different fr
11 matches
Mail list logo
