Received: from u1.abs.net (root@u1.abs.net [207.114.0.131]) by hub.org (8.8.8/8.7.5) with ESMTP id QAA10182 for ; Tue, 28 Jul 1998 16:07:18 -0400 (EDT) Received: from insightdist.com (nobody@localhost) by u1.abs.net (8.9.0/8.9.0) with UUCP id PAA02533 for pgsql-interfaces@postgreSQL.org; Tue, 28 Jul 1998 15:41:14 -0400 (EDT) X-Authentication-Warning: u1.abs.net: nobody set sender to insightdist.com!byronn using -f Received: from ceodev by insightdist.com (AIX 3.2/UCB 5.64/4.03) id AA20635; Tue, 28 Jul 1998 15:34:56 -0400 Received: from byronn by ceodev (AIX 4.1/UCB 5.64/4.03) id AA63312; Tue, 28 Jul 1998 15:34:56 -0400 Message-Id: <35BE27E7.6BCD6C3@insightdist.com> Date: Tue, 28 Jul 1998 15:35:04 -0400 From: Byron Nikolaidis X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 To: wojtek Cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] Error 'Named portals' References: <35BE161F.B78903D9@itl.waw.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit wojtek wrote: > DROP TABLE mybackup;ALTER TABLE mybase RENAME TO mybackup; > One of the problems is because the driver is sending this as a single command to Postgres. Since the first part of the command errors out, the second part is never even executed. The solution to this is to break up the commands into single commands and then send each to the backend, like pgsql already does. > ERROR: Named portals may only be used in begin/end transaction blocks > #I don't understand it. What does it mean? What happened with > #rename operation? There should appear error message, because > #there was no 'mybase' base yet. > A query is performed right after the connect settings is sent to discover if there is a large object oid type defined in your database. It looks like this: declare SQL_CUR0123456 cursor for select oid from pg_type where typname='lo'. This query is inside the BEGIN which occurred prior to the ERROR above. Since the transaction is now in a bad state because of that error, it complains about the declare/cursor not being inside a transaction, which Postgres requires. This is also caused by the driver. It should have aborted the transaction when the error occured. Then begin another one for the next query. It normally does this, but not in the Connect Settings because they are handled differently. Or perhaps, none of the connection stuff should even be in a transaction. I am going to overhaul this ConnectSettings process. It is going to send each command separately now and handle errors better. Byron