Hello nice people,

Slowly & happily I'm becoming a PostgreSQL hacker ;-) What a pleasure. Last
days, I learned to use the debugger, to follow code, & understood some of
PostgreSQL internals. In spanish we say someone is a 'cabeza dura' when tries
hard to do something against the odds, & so am I. My goal is to make the backend
accept erroneous commands, not falling in *ABORT STATE*, but rolling back
automatically, & continue accepting commands. So I found that there is a
function StartTransactionCommand(), which does things before executing commands,
depending on transaction state. And it did nothing explicitely when
TBLOCK_ABORT. So I added three lines, which pretend to set the backend in a safe
state, and I think I did it. What do you think about this? In my early tests, it
works. It complains saying something about the transaction state, but works
anyway. I think that by polishing it, the complain can be eliminated.



                case TBLOCK_ABORT:
+                        s->blockState = TBLOCK_INPROGRESS;
+                        AbortTransaction();
+                        StartTransaction();
                        break;


So now I can give back to PostgreSQL a 0.1% of what it gave to me. Thanks.

Cheers,
Haroldo.

P.S. Now I'll have to learn java, to make the JDBC give errors analogous to
Informix, so that my CASE tool thinks it talks to Informix. Someone posted
something about more analyzable error messages by PostgreSQL, maybe we can chat
about it.

-- 
----------------------+------------------------
 Haroldo Stenger      | hstenger@ieee.org
 Montevideo, Uruguay. | hstenger@adinet.com.uy
----------------------+------------------------
 Visit UYLUG Web Site: http://www.linux.org.uy
-----------------------------------------------

Mon, 31 Jul 2000 11:11:53 -0300
hstenger@adinet.com.uy
Now PostgreSQL recovers from errors within trns
hstenger@adinet.com.uy writes:
> My goal is to make the backend accept erroneous commands, not falling
> in *ABORT STATE*, but rolling back automatically, & continue accepting
> commands.

The way you're doing it, you might as well just not use transaction
blocks at all.  I don't think wiping out the effects of all preceding
commands within the transaction counts as "recovering from an error".

			regards, tom lane

Mon, 31 Jul 2000 11:08:03 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Now PostgreSQL recovers from errors within trns 
At 02:10 PM 7/31/00 -0300, hstenger@adinet.com.uy wrote:
>Tom Lane wrote:
>> 
>> hstenger@adinet.com.uy writes:
>> > My goal is to make the backend accept erroneous commands, not falling
>> > in *ABORT STATE*, but rolling back automatically, & continue accepting
>> > commands.
>> 
>> The way you're doing it, you might as well just not use transaction
>> blocks at all.  I don't think wiping out the effects of all preceding
>> commands within the transaction counts as "recovering from an error".
>
>Ok, maybe I exagerated, but kind of solves my problem. GeneXus, my CASE tool,
>will send begin/commit pairs, so I must 'recover' automatically. I aimed
>DB2-like behaviour, which I was told, aborts on errors within
transactions, but
>remains in a runnable state. Don't you consider it valueable whatsoever?

Well, Postgresql's behavior isn't SQL92 compliant, but neither is the 
behavior you want.  I far prefer the current non-standard behavior.
Eventually,
of course, PG should conform to SQL92.

GeneXus should be catching the error and issuing a rollback if that's
the behavior it expects.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Mon, 31 Jul 2000 10:05:12 -0700
Don Baccus <dhogaza@pacifier.com>
Re: Now PostgreSQL recovers from errors within trns
Tom Lane wrote:
> 
> hstenger@adinet.com.uy writes:
> > My goal is to make the backend accept erroneous commands, not falling
> > in *ABORT STATE*, but rolling back automatically, & continue accepting
> > commands.
> 
> The way you're doing it, you might as well just not use transaction
> blocks at all.  I don't think wiping out the effects of all preceding
> commands within the transaction counts as "recovering from an error".

Ok, maybe I exagerated, but kind of solves my problem. GeneXus, my CASE tool,
will send begin/commit pairs, so I must 'recover' automatically. I aimed
DB2-like behaviour, which I was told, aborts on errors within transactions, but
remains in a runnable state. Don't you consider it valueable whatsoever?

Haroldo.

-- 
----------------------+------------------------
 Haroldo Stenger      | hstenger@ieee.org
 Montevideo, Uruguay. | hstenger@adinet.com.uy
----------------------+------------------------
 Visit UYLUG Web Site: http://www.linux.org.uy
-----------------------------------------------

Mon, 31 Jul 2000 14:10:16 -0300
hstenger@adinet.com.uy
Re: Now PostgreSQL recovers from errors within trns
Don Baccus wrote:
> Well, Postgresql's behavior isn't SQL92 compliant, but neither is the
> behavior you want.  I far prefer the current non-standard behavior.
> Eventually,
> of course, PG should conform to SQL92.

This change is not a must. Is very optional. Since I solved a problem, I'happy.
I don't know much about the standards, but agree with you just in case.

> GeneXus should be catching the error and issuing a rollback if that's
> the behavior it expects.

Yup, but GeneXus is closed source, and PostgreSQL is open source. I'm trying to
convince GeneXus' ARTech (www.genexus.com.uy) about the importance of supporting
PostgreSQL. From the PostgreSQL point of view, if this has place someday,
PostgreSQL will gain a lot of corporate users, and a whole new consulting field
will be available. Do you understand my point? 


-- 
----------------------+------------------------
 Haroldo Stenger      | hstenger@ieee.org
 Montevideo, Uruguay. | hstenger@adinet.com.uy
----------------------+------------------------
 Visit UYLUG Web Site: http://www.linux.org.uy
-----------------------------------------------

Mon, 31 Jul 2000 14:30:40 -0300
hstenger@adinet.com.uy
Re: Now PostgreSQL recovers from errors within trns
On Mon, Jul 31, 2000 at 02:30:40PM -0300, hstenger@adinet.com.uy wrote:
> 
> Yup, but GeneXus is closed source, and PostgreSQL is open source. I'm trying to
> convince GeneXus' ARTech (www.genexus.com.uy) about the importance of supporting
> PostgreSQL. From the PostgreSQL point of view, if this has place someday,
> PostgreSQL will gain a lot of corporate users, and a whole new consulting field
> will be available. Do you understand my point? 
> 

As an aside, to the hackers (and Ned Lilly, in particular) This sort
of corporate evangalism is one avenue in which I could see BreatBridge
being very helpful to the PostgreSQL community. Find out what SQL CASE/CAD
what-have-you tools are in use in businesses out there, and work with the
tool makers to support PostgreSQL out-of-the-box. Existing end users (and
potential end users) need to make noise too, of course, but GreateBridge
would be in the position to credibly tell the tool builders how much
effort it might be to support pgsql. Heck, for the lower end of these
tools, they could package pgsql with the tool, to provide a working,
functional system, with an "upgrade" path to commericial systems.
A lot of those systems would just never find the need top upgrade,
would be my bet.

Hmm, a quick survey over on GENERAL might get a starter list of tools
to target. Myself, I've looked at Embarcadero Technology's "lifecycle"
tools: ER/Studio FastSQL, DBArtisan. They look interesting, and sort of
work with the ODBC driver, but could use some tweaking to unserstand a
pgsql installion better.

http://www.embarcadero.com/

Another, not quite the same category, but interesting, one is a
replication/remote access layer we looked at about a year ago: ISG
Navigator. Hmm, seems to have been renamed to AttunityConnect.  That one
was very flexible: could be tuned by editing a config file with various
'features' flags.

http://www.attunity.com/

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Mon, 31 Jul 2000 13:08:33 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Now PostgreSQL recovers from errors within trns