Re: PERFORM statement inside procedure - Mailing list pgsql-general

From Richard Huxton
Subject Re: PERFORM statement inside procedure
Date
Msg-id 200404070928.25951.dev@archonet.com
Whole thread Raw
In response to Re: PERFORM statement inside procedure  ("Rajat Katyal" <rajatk@intelesoftech.com>)
List pgsql-general
On Wednesday 07 April 2004 08:30, Rajat Katyal wrote:
> Actually my problem is PERFORM is not updating the FOUND variable to false
> even when my query return no rows. Can you please tell me the better way to
> use PERFORM so that by running my select query I just come to know whether
> it returns 0 rows or not.

No, what Tom's saying is that PERFORM doesn't take a string - you are passing
it a string. Since perform is equivalent to SELECT that means you are doing
  SELECT 'SELECT true'
which returns one row, containing one column: 'SELECT true'

If you want to execute a string as a query, you use EXECUTE. Execute slows the
process down because it actually runs the query.

If you want to use PERFORM you'll need to write something like:

PERFORM SELECT true FROM transform_customer_billing WHERE inv_no = NEW.inv_no;
IF FOUND THEN
...

(The only reason I select true rather than * is so I don't think I'm going to
use the results from this query when I look at the code 12 months from now).

PS - that will slow the process down again. I'm not sure you want to be doing
what you're trying to do. Your original problem (a couple of weeks ago?)
seemed to be inserts/updates were half the speed if you checked for the
existence of the row yourself. Not surprising, you're doing two things. But,
you wanted to do this because you didn't know if you were updating or
inserting.

In cases like this, I prefer to remove the unknown. Where I need a customer to
have a balance total, I add a trigger to the customer table so that every
time a new customer is inserted, so is a zeroed row to the balance table.
Deny deletion of balance rows where its customer still exists and you can
safely issue updates all the time.

--
  Richard Huxton
  Archonet Ltd

pgsql-general by date:

Previous
From: David Garamond
Date:
Subject: More aggregate functions?
Next
From: David Garamond
Date:
Subject: Re: Can we have time based triggers in Postgresql??