BUG #1059: Second Call of a PGSQL-function fails

Started by PostgreSQL Bugs Listover 22 years ago3 messagesbugs
Jump to latest
#1PostgreSQL Bugs List
pgsql-bugs@postgresql.org

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

#2Richard Huxton
dev@archonet.com
In reply to: PostgreSQL Bugs List (#1)
Re: BUG #1059: Second Call of a PGSQL-function fails

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

#3Bruce Momjian
bruce@momjian.us
In reply to: PostgreSQL Bugs List (#1)
Re: BUG #1059: Second Call of a PGSQL-function fails

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