Tom Lane wrote:
> Michael Ansley <[EMAIL PROTECTED]> 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.
EXECUTE simply takes the string expression and throws it into
SPI_exec() without parsing. Changing that for 7.1 is *not*
possible.
The above can be accomplished by
DECLARE
ROW record;
RES integer;
BEGIN
FOR ROW IN EXECUTE
''SELECT count(*) AS N FROM '' || $1
LOOP
RES := N;
END LOOP;
RETURN RES;
END;
Not as elegant as it should be, but at least possible.
There's much to be done for a future version of PL/pgSQL, but
better support for dynamic SQL needs alot of functionality
added to the main parser and the SPI manager in the first
place.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
