Обсуждение: BUG #1059: Second Call of a PGSQL-function fails

The following bug has been logged online:

Bug reference:      1059
Logged by:          Wilhelm

Email address:      wilhelm.pakulla@gmx.de

PostgreSQL version: 7.4

Operating system:   Linux

Description:        Second Call of a PGSQL-function fails

Details:

-- The Source:

-- Init Stuff
DROP FUNCTION plpgsql_call_handler () CASCADE;
CREATE FUNCTION plpgsql_call_handler () RETURNS LANGUAGE_HANDLER AS
'$libdir/plpgsql' LANGUAGE C;

CREATE TRUSTED PROCEDURAL LANGUAGE plpgsql
    HANDLER plpgsql_call_handler;

-- The function

CREATE FUNCTION f (INTEGER) RETURNS INTEGER
AS '
BEGIN
  CREATE TABLE test ( x INTEGER );

  -- Without this insert, everything works well...
  INSERT INTO test VALUES (1);

  DROP TABLE test CASCADE;

  RETURN 0;
END;
' LANGUAGE 'plpgsql';

-- That works.
SELECT f(1);

-- Second Call fails.
SELECT f(1);

-- Thanks in advance, Wilhelm

On Wednesday 21 January 2004 21:24, PostgreSQL Bugs List wrote:
> Bug reference:      1059
> Logged by:          Wilhelm
> Email address:      wilhelm.pakulla@gmx.de
>
> PostgreSQL version: 7.4
> Operating system:   Linux
> Description:        Second Call of a PGSQL-function fails

Wilhelm - this is a known behaviour (I'm not sure it can be called a bug).

Because plpgsql is a compiled language, it converts references to tables and
other objects to their internal OID number. If you drop a table then recreate
it, it will get a new OID and your function will no longer be able to find
it.

There are two ways to deal with this:
1. Don't use plpgsql for these functions, use SQL or TCL/Perl/some other
interpreted language
2. Use EXECUTE to build a query from a string.

You should find plenty on this in the mailing list archives, usually in
connection to TEMPorary tables.

HTH

PS - If you think the documentation needs clarifying, suggestions on wording
are always appreciated, preferably on pgsql-docs mailing list.

--
  Richard Huxton
  Archonet Ltd

We have an FAQ for this:

    <H4><A name="4.26">4.26</A>) Why can't I reliably create/drop
    temporary tables in PL/PgSQL functions?</H4>

It says temporary tables, but it is valid for real tables too when you
creating/dropping them in the function.

---------------------------------------------------------------------------

PostgreSQL Bugs List wrote:
>
> The following bug has been logged online:
>
> Bug reference:      1059
> Logged by:          Wilhelm
>
> Email address:      wilhelm.pakulla@gmx.de
>
> PostgreSQL version: 7.4
>
> Operating system:   Linux
>
> Description:        Second Call of a PGSQL-function fails
>
> Details:
>
> -- The Source:
>
> -- Init Stuff
> DROP FUNCTION plpgsql_call_handler () CASCADE;
> CREATE FUNCTION plpgsql_call_handler () RETURNS LANGUAGE_HANDLER AS
> '$libdir/plpgsql' LANGUAGE C;
>
> CREATE TRUSTED PROCEDURAL LANGUAGE plpgsql
>     HANDLER plpgsql_call_handler;
>
> -- The function
>
> CREATE FUNCTION f (INTEGER) RETURNS INTEGER
> AS '
> BEGIN
>   CREATE TABLE test ( x INTEGER );
>
>   -- Without this insert, everything works well...
>   INSERT INTO test VALUES (1);
>
>   DROP TABLE test CASCADE;
>
>   RETURN 0;
> END;
> ' LANGUAGE 'plpgsql';
>
> -- That works.
> SELECT f(1);
>
> -- Second Call fails.
> SELECT f(1);
>
> -- Thanks in advance, Wilhelm
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073