granularity is an odd label to denounce and replace scattering, as i can think of nothing that scatters more than grains.

generally, conditional triggers could be used by a platform layer that would automate the creation and updating of these triggers, but in the name of portability, that layer could handle such scheduling and processing on it's own.

if you're a farmer, do you want to "harvest the field" or "pick up every grain of corn"... as a programmer, do you want to "update the codebase" or "find every piece of the codebase you need to update"...

it's not FUD... it's a waste of time.

i agree completely... when the OP said he would use it "in a lot of scenarios" my red flag of maintainability went up hard.

for example, if you're doing column when triggers, and initially you want to do something on a boolean conditional, you'll probably code the trigger as such... but now you add in a new column type and in debugging you find out the trigger isn't going off, and now you have to leave the code you're adding for the new condition to exist, and find and update the trigger code. i simply find that whatever process that allowed you to create the new condition should have also handled the payload of the trigger. code scattering is my biggest pet peeve in system engineering.

you're all idiots.

ur mum's face requires professional help.

you are NOTHING

what's up with this site attempting to restrict access by user, but not restricting access to users by people? what's up you caring about what i have instead of what you don't have?

ur mum's face is an idiot.

internet "toughguy" exercising their last resort

a hypocrite to boot. you're an idiot.