Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Cool (Score 1, Interesting) 344

by MichaelDavKristopeit (#33644230) Attached to: PostgreSQL 9.0 Released
i'm not saying conditional triggers shouldn't exist... and i'm agreeing that more cycles would be used if a trigger was used where a conditional trigger could have been used, but my point is that in such situations the same job could be done without using any triggers whatsoever.

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.

Comment: Re:Cool (Score 1) 344

by MichaelDavKristopeit (#33643688) Attached to: PostgreSQL 9.0 Released

Not that this isn't nice, but it may also lead to code scattering, increasing maintainability issues.

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.

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.

Working...