Re: [INTERFACES] Error 'Named portals'

From: Byron Nikolaidis <byronn(at)insightdist(dot)com>
To: wojtek <wojtek(at)itl(dot)waw(dot)pl>
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] Error 'Named portals'
Date: 1998-07-28 19:35:04
Message-ID: 35BE27E7.6BCD6C3@insightdist.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Bruce Momjian 1998-07-29 04:59:32 Re: [HACKERS] Coping with backend crash in libpq
Previous Message Tom Lane 1998-07-28 19:06:56 libpgtcl crashes after backend crash