Karl, > I like to write PERFORMs that return a constant when > selecting from a table. It emphasizes that the > selection is being done for its side effects.
Well, there's always the destruction test: run each version of the function 10,000 times and see if there's an execution time difference. > (Programs should be written for people to read > and only incidentally for computers to execute. > Programs that people can't read quickly > become useless whereas programs that can't run > quickly can be fixed. Computers are easy. > People are difficult.) That's a nice sentiment, but I don't see how it applies. For example, if I do: SELECT id INTO v_check FROM some_table ORDER BY id LIMIT 1; IF id > 0 THEN .... ... that says pretty clearly to code maintainers that I'm only interested in finding out whether there's any rows in the table, while making sure I use the index on ID. If I want to make it more clear, I do: -- check whether the table is populated Not that there's anything wrong with your IF FOUND approach, but let's not mix up optimizations and making your code pretty ... especially for a SQL scripting language. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match