Re: [SQL] PL/PGSQL function with parameters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Ansley <Michael(dot)Ansley(at)intec-telecom-systems(dot)com>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, sqllist <pgsql-sql(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [SQL] PL/PGSQL function with parameters
Date: 2001-02-06 16:16:01
Message-ID: 25204.981476161@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Michael Ansley <Michael(dot)Ansley(at)intec-telecom-systems(dot)com> writes:
> CREATE FUNCTION table_count(varchar) RETURNS integer AS '
> DECLARE
> SQL varchar;
> RES integer;
> BEGIN
> SQL = ''SELECT * INTO temp1 FROM '' || $1;
> EXECUTE SQL;
> SELECT count(*) INTO RES FROM temp1;
> RETURN(RES)
> END;
> '
> LANGUAGE 'plpgsql';

> What I couldn't get it to do was to select directly into the variable RES.

I tried this, and it seems that "SELECT ... INTO foo" is not executed
correctly by EXECUTE --- the INTO is handled as an ordinary select-into-
table construct rather than plpgsql's select-into-variable.

While I have not looked closely, I seem to recall that plpgsql handles
INTO by stripping that clause out of the statement before it's passed to
the SQL engine. Evidently that's not happening in the EXECUTE case.

Jan, do you agree this is a bug? Is it reasonable to try to repair it
for 7.1? If we do not change the behavior of EXECUTE now, I fear it
will be too late --- some people will come to depend on the existing
behavior.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Ansley 2001-02-06 16:27:56 RE: [SQL] PL/PGSQL function with parameters
Previous Message Mitch Vincent 2001-02-06 16:15:59 Re: full text searching

Browse pgsql-sql by date

  From Date Subject
Next Message Michael Ansley 2001-02-06 16:27:56 RE: [SQL] PL/PGSQL function with parameters
Previous Message Tom Lane 2001-02-06 16:05:15 Re: CREATE TABLE AS and ORDER BY