Tom Lane wrote:
Do you really need an EXECUTE? If so, maybe you could restructure this
using a FOR ... IN EXECUTE, or some such thing.
I'll always only ever have a single result since the function gets
passes all the fields making up the primary key of the table, so doing a
for in seems like it's doing more work than is needed.
I need an execute because I'm dynamically constructing an SQL statement
based on the parameters passed into the function - unless there is some
other way of doing it that I'm not aware of.
therefore I just be using a test of IF curr_amount IS NOT NULL?
Well, that might work. Have you thought through the corner case
where the query does find a row but the field's value is null?
The field in question is marked not null in the tables schema, so unless
PG lets things get past this constraing I don't believe that would be an
issue.
Having the test at is not null seems to be doing the job.
Thanks.
--
Paul Lambert
Database Administrator
AutoLedgers - A Reynolds & Reynolds Company
---------------------------(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
