Skip site navigation (1) Skip section navigation (2)

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

From: Richard Huxton <dev(at)archonet(dot)com>
To: "PostgreSQL Bugs List" <pgsql-bugs(at)postgresql(dot)org>
Cc: wilhelm(dot)pakulla(at)gmx(dot)de
Subject: Re: BUG #1059: Second Call of a PGSQL-function fails
Date: 2004-01-22 02:02:36
Message-ID: 200401220202.36764.dev@archonet.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On Wednesday 21 January 2004 21:24, PostgreSQL Bugs List wrote:
> Bug reference:      1059
> Logged by:          Wilhelm
> Email address:      wilhelm(dot)pakulla(at)gmx(dot)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

In response to

pgsql-bugs by date

Next:From: PostgreSQL Bugs ListDate: 2004-01-22 08:53:36
Subject: BUG #1060: psql encoding bug : sjis
Previous:From: PostgreSQL Bugs ListDate: 2004-01-21 21:24:43
Subject: BUG #1059: Second Call of a PGSQL-function fails

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group