Outer join, please!

I was shown this piece of SQL gems:

delete from bad_table where name not in (select name from good_table);

Then something like "it has always fast until now". So I straighten this code to:

delete from bad_table where name in
(select b.name from bad_table b, good_table g
where b.name = g.name(+) and g.name is null)

The first query was fast but is low now because bad_table has grown since the code went into production. Yay! outer join saves the day!

sizeof hurts me!

I should be sent back to cs101 (introduction to c programming) for writing shit like this recently:

int matrix[] = { 1, 3, 7, 11};
int i;
for (i=0; i < sizeof(matrix); i++)
{
       blah...blah...blah...;
}

My instinct tells me the "sizeof" above will return more than 4 but there a voice in me that says "nah, the compiler will sort it out". Wrong! *dope slap*

Somewhere along my programming trip, I thought I remember that sizeof is a smart function! Sort of like the pointer incremental operator... you know, how it will move to the correct memory location depending on the type... Oh well, I must be mixing c up with Pascal or something... too many programs and yet still too long to go before I'm asleep.

fclose

How many time I and others have done this:

int error = 0;
FILE *fp = fopen("blad", "w");
if (fp){
  while (getStuff( data, &dataLen)){
    if (fwrite( data, dataLen, 1, fp) != dataLen){
      error = 1;
      break;
    }
  }
  fclose(fp);
}
else
  error = 1;
return error

Note that no error checking is done on fclose! the code meticulously checks the write process but neglects the final file closure.

A piece of code like this from an old data collection service program (> 10 years ago) burned me recently. Our enormous disk array filled up (for reason too lame to discuss) and it was never noted by this program. It just saved data to out zero bytes files! All the redundancies we put in place to prevent data loss failed because of this one piece of code.