Most recent driver aborts transaction after one error

This is a multi-part message in MIME format.
--------------030509070803050902060909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,

I have just upgraded to PostgreSQL 8.1 and I have encountered the
following problem. When I connect through psqlODBC 8.01.0200 (PostgreSQL
Unicode), a sequence like the following:


DROP SEQUENCE BAZ;
SELECT 1;

will give an error on the DROP SEQUENCE:

"42P01: Error while executing the query;
ERROR: sequence "app_bod_seq" does not exist"

and will then give an error on the SELECT 1:

"25P02: Error while executing the query;
ERROR: current transaction is aborted, commands ignored until end of
transaction block"

When connecting through the psqlODBC 8.00.0102, I do *not* get the
second error. This is, in fact, what I would expect. It is also what
pretty much all other databases do (our application also runs on
Informix, Firebird, Oracle and MS SQL Server, and they all allow failed
commands in transactions without forcing a rollback). And it is what the
8.00.0102 driver did. Was this behaviour changed on purpose, and if so,
why? Please enlighten me!

--Bart

P.S.: I'm not subscribed to the list, please keep me CC'ed!

--------------030509070803050902060909
Content-Type: text/plain;
name="mylog_1332.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="mylog_1332.log"

[3348]globals.extra_systable_prefixes = 'dd_;'
[3348]aszKey='DSN', value='postgres'
[3348]copyAttributes: DSN='postgres',server='',dbase='',user='',passwd='xxxxx',por t='',sslmode='',onlyread='',conn_settings='',disallow_premat ure=-1)
[3348]globals.extra_systable_prefixes = 'dd_;'
[3348]globals.extra_systable_prefixes = 'dd_;'

--------------030509070803050902060909
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

--------------030509070803050902060909--

Re: Most recent driver aborts transaction after one error

Please ignore this message, it was stuck in the moderation queue.

--Bart

Bart Samwel wrote:
> Hi there,
>
> I have just upgraded to PostgreSQL 8.1 and I have encountered the
> following problem. When I connect through psqlODBC 8.01.0200 (PostgreSQL
> Unicode), a sequence like the following:
>
>
> DROP SEQUENCE BAZ;
> SELECT 1;
>
> will give an error on the DROP SEQUENCE:
>
> "42P01: Error while executing the query;
> ERROR: sequence "app_bod_seq" does not exist"
>
> and will then give an error on the SELECT 1:
>
> "25P02: Error while executing the query;
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block"
>
> When connecting through the psqlODBC 8.00.0102, I do *not* get the
> second error. This is, in fact, what I would expect. It is also what
> pretty much all other databases do (our application also runs on
> Informix, Firebird, Oracle and MS SQL Server, and they all allow failed
> commands in transactions without forcing a rollback). And it is what the
> 8.00.0102 driver did. Was this behaviour changed on purpose, and if so,
> why? Please enlighten me!
>
> --Bart
>
> P.S.: I'm not subscribed to the list, please keep me CC'ed!
>
>
> ------------------------------------------------------------ ------------
>
> [3348]globals.extra_systable_prefixes = 'dd_;'
> [3348]aszKey='DSN', value='postgres'
> [3348]copyAttributes: DSN='postgres',server='',dbase='',user='',passwd='xxxxx',por t='',sslmode='',onlyread='',conn_settings='',disallow_premat ure=-1)
> [3348]globals.extra_systable_prefixes = 'dd_;'
> [3348]globals.extra_systable_prefixes = 'dd_;'
>
>
> ------------------------------------------------------------ ------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly