Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA05577; Tue, 10 Aug 93 08:55:30 -0700
Date: Tue, 10 Aug 93 08:55:30 -0700
Message-Id: <9308101555.AA05577@postgres.Berkeley.EDU>
From: jean@gso.SAIC.COM (Jean Anderson)
Subject: Re: portal renaming?
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu

Ranen Goren <ranen@CS.HUJI.AC.IL> writes:

> Retrieve commands, which have no 'into', 'portal' or 'iportal'
> keywords, go all to the 'blank' portal.
>                       ... What I need is some mechanism to either
> rename the portal's name from 'blank' to something else, or to
> copy the entire portal contents into a new portal. Or maybe
> something I didn't think about?

and jaws@pangaea.dme.nt.gov.au (James Woods 61-89-895257) writes:

> I have been thinking on this also, one idea I had was to parse the query
> and if there is a retrieve, insert a portal name after in.  This will have
> to be refined for more complex queries, and is a bit of a hack.  But if noone
> has a better idea it is probably worth a try.

I have been doing it with a brute force strtok() hack, as in:

        c = strtok(query_copy, " \n\t");      /* "retrieve" already verified */
        c = strtok((char *)NULL," \n\t");     /* "portal", maybe   */

        if (!strcmp(c, "portal"))
        ....

If the user specifies a portal name I grab it and use it. If not, I 
rewrite the query behind the scenes to use a named portal. This is to 
eventually support returning to a fetch so a program can process query 
results in batches.

And -- whoops! :-) -- I forgot about "into", so let's keep the thread going.
What other retrieves should be left alone?

The query rewrite hack gets rapidly messy because named portals require a 
transaction and only one transaction is allowed.  So I track transaction 
state and only 'begin' a transaction if one has not already been started 
and only 'end' it if I started it. I also intercept the begin, end, and 
abort commands and set my transaction tracker accordingly.

Does anybody know of a way to snag current transaction state from Postgres?

This works fine as long as all is well in query land. But it rapidly falls
apart when errors occur.  What's the state of the transaction if the user 
retrieves a nonexistent object or has a typo in the query? Some errors 
cause a transaction to automatically abort. When should you explicitely
abort the transaction after an error occurs? when should you leave it alone?
These are the sorts of things I'm trying to iron out.

Tangled web, eh?

Does anybody have a simpler solution?

regards,

 - jean
   jean@gso.saic.com