I've handled to produce a small testcase: http://strk.keybit.net/tmp/could_not_open_relation.sql
It still requires postgis (svn), but if anyone has that it might help. Will try to go on with the reduction. --strk; On Mon, Feb 07, 2011 at 12:38:08PM +0100, strk wrote: > Hi all, > I'm trying to debug an ugly error triggered from a "DROP SCHEMA xxx CASCADE" > call inside a function. > > The call is the last step of the stored pl/pgsql procedure. > > I've verified that removing the "DROP SCHEMA" command from _inside_ > the function body and performing it _outside_ it (right after return) > everything works fine. > > Note that the schema that the function is trying to drop was created > by a function called by the function attempting to drop it. > Both function (the one which creates the schema and the one which > attempts to drop it) are defined as VOLATILE. > > Also, I can see traces of the DROP SCHEMA CASCADE being executed, till > the ERROR comes out (lots of traces for cascading objects). > > This is : > PostgreSQL 8.4.3 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real > (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit > > Do you have an idea on how to further debug this ? > TIA. > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html -- () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
