X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id A333CD1B49A for ; Sat, 29 Nov 2003 03:10:29 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 43149-01 for ; Fri, 28 Nov 2003 23:10:02 -0400 (AST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id A6B9AD1C9CE for ; Fri, 28 Nov 2003 23:09:58 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id D594C354D1; Fri, 28 Nov 2003 19:09:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id D2336354C3; Fri, 28 Nov 2003 19:09:47 -0800 (PST) Date: Fri, 28 Nov 2003 19:09:47 -0800 (PST) From: Stephan Szabo To: FET Cc: pgsql-sql@postgresql.org Subject: Re: Stored procedures and relations In-Reply-To: Message-ID: <20031128190810.J52057@megazone.bigpanda.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/336 X-Sequence-Number: 16151 On Fri, 28 Nov 2003, FET wrote: > Hi everybody, > I have a stored procedure that drops table A and then creates table A > again. The table A has no constraints on any columns. When I execute > the stored procedure by saying: SELECT sp_myproc(); It gives me an > error saying : Relation 68428 does not exist. > > When I remove the CREATE FUNCTION and the stuff used to make it a > stored procedure, and run the commands in the procedure, it works > correctly. > > This behaviour is observed on all stored procedures on PG-SQL. I would > really appreciate any help or interpretation of this error. By the > way, the same stored procedure (with the syntax changed of course) > works perfectly on MS SQL Server. You haven't given too many details about what your function does, but, in general if you're accessing a table whose structure is being dynamically modified during/between calls, you'll currently want to be using EXECUTE on queries relating to that table.