Subject: Re: portal renaming?

From: [email-masked] (Jean Anderson)
Date: Tue, 10 Aug 93 08:55:30 -0700

Ranen Goren <[email-masked]> 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 [email-masked] (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
   [email-masked]

---

From: Ranen Goren <[email-masked]>
Date: Thu, 12 Aug 1993 18:02:06 +0300

[email-masked] (Jean Anderson) wrote:

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

	Sure... Just PQexec("begin") and parse the output message
	to see if Postgres claims it is already in transaction mode :)
	If you really want to make it bulletproof, I guess
	you are inviting trouble. I have started to think about
	pressing the user's Help button ;)

		Ranen