On Wed, 2004-08-18 at 02:48, Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
This behaviour allows much closer mimicking of Oracle and other RDBMS's
transactional behaviour
begin 2cThis is my single biggest pet peeve with Postgres. When I was first
starting it was the single
On Tue, Aug 17, 2004 at 02:56:19PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Doing it only for interactive mode seems too error-prone to me (it works
in psql, but not from my script).
You're missing the point: a script cannot safely work this way. A human
typing at
It is not just a typo that you make in the SQL command. You often need
to do
insert into table which has primary key
if the insert failed, do update of the existing record
Do the update first then the insert.
Chris
---(end of
On Wed, Aug 18, 2004 at 02:47:26PM +0800, Christopher Kings-Lynne wrote:
It is not just a typo that you make in the SQL command. You often need
to do
insert into table which has primary key
if the insert failed, do update of the existing record
Do the update first then the
Philip Warner wrote:
At 01:47 AM 12/08/2004, Tom Lane wrote:
It might be reasonable to offer that behavior as an option, but I think
I'd only want it on for interactive input.
My preference would be for something like:
set savepoint_per_statement=true
then interactive scripts
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO list:
* Add an option to automatically use savepoints for each statement in a
multi-statement transaction.
When enabled, this would allow errors in multi-statement transactions
to be automatically ignored.
Note that whoever
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO list:
* Add an option to automatically use savepoints for each statement in a
multi-statement transaction.
When enabled, this would allow errors in multi-statement transactions
to be automatically ignored.
Like I said, my
Hi Tom
On Wed, 11 Aug 2004 11:47:35 -0400, Tom Lane [EMAIL PROTECTED] wrote:
The other objection is that this would create very substantial overhead.
why?
It might be reasonable to offer that behavior as an option, but I think
I'd only want it on for interactive input.
How could the server
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO list:
* Add an option to automatically use savepoints for each statement in a
multi-statement transaction.
When enabled, this would allow errors in multi-statement transactions
to be automatically ignored.
Haroldo Stenger [EMAIL PROTECTED] writes:
On Wed, 11 Aug 2004 11:47:35 -0400, Tom Lane [EMAIL PROTECTED] wrote:
It might be reasonable to offer that behavior as an option, but I think
I'd only want it on for interactive input.
How could the server tell interactive input from scripted intput
Bruce Momjian [EMAIL PROTECTED] writes:
Doing it only for interactive mode seems too error-prone to me (it works
in psql, but not from my script).
You're missing the point: a script cannot safely work this way. A human
typing at the terminal can notice that his command failed and react to
Bruce Momjian
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO list:
* Add an option to automatically use savepoints for each
statement in a
multi-statement transaction.
When enabled, this would allow errors in multi-statement
transactions
to be
On Tue, Aug 17, 2004 at 03:33:01PM -0300, Haroldo Stenger wrote:
Haroldo,
On Wed, 11 Aug 2004 11:47:35 -0400, Tom Lane [EMAIL PROTECTED] wrote:
The other objection is that this would create very substantial overhead.
why?
Establishing a savepoint is a non-trivial operation (cost-wise).
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
Establishing a savepoint is a non-trivial operation (cost-wise). Several
internal server structures have to be prepared for it.
Check
It's way cheaper than normal transaction start and commit,
Is it? You have the same amount of work to do
Hola Alvaro
On Tue, 17 Aug 2004 16:58:56 -0400, Alvaro Herrera Munoz
[EMAIL PROTECTED] wrote:
On Wed, 11 Aug 2004 11:47:35 -0400, Tom Lane [EMAIL PROTECTED] wrote:
The other objection is that this would create very substantial overhead.
why?
Establishing a savepoint is a non-trivial
At 07:10 AM 18/08/2004, Tom Lane wrote:
I have not had an opportunity to benchmark it but I fear a savepoint may
cost near as much as a full xact in practice.
Out of curiosity, does this mean that using a savepoint per statement will
be no worse than using psql in autocommit mode?
At 04:44 AM 18/08/2004, Bruce Momjian wrote:
it turns off when the transaction completes?
Not sure I like this part; I would like to be able to set the variable at
the start of a psql session and have it run for the entire session. Or,
even better, set it in a psql initialization file.
Also,
At 09:26 AM 18/08/2004, Philip Warner wrote:
Also, will the 'interactive-session' check consider an included file (\i)
to be interactive? I'd vote yes.
In retrospect, I assume the interactive-session limit would not be a
problem here since the command would be entered interactively. The source
On Tue, Aug 17, 2004 at 08:21:13PM -0300, Haroldo Stenger wrote:
Hola,
On Tue, 17 Aug 2004 16:58:56 -0400, Alvaro Herrera Munoz
[EMAIL PROTECTED] wrote:
Establishing a savepoint is a non-trivial operation (cost-wise). Several
internal server structures have to be prepared for it. It's
On Wed, Aug 18, 2004 at 09:23:44AM +1000, Philip Warner wrote:
At 07:10 AM 18/08/2004, Tom Lane wrote:
I have not had an opportunity to benchmark it but I fear a savepoint may
cost near as much as a full xact in practice.
Out of curiosity, does this mean that using a savepoint per statement
Simon Riggs [EMAIL PROTECTED] writes:
This behaviour allows much closer mimicking of Oracle and other RDBMS's
transactional behaviour
begin 2cThis is my single biggest pet peeve with Postgres. When I was first
starting it was the single most frustrating violation of the least surprise
On 17 Aug 2004, Greg Stark wrote:
With Postgres I effectively have to work in autocommit mode. Starting over
from scratch every time I make a typo is infeasible. It feels like trying to
type in a C program using cat. I've done it before but it's not something I
want to repeat often.
I agree.
In 8.0 beta 1 I just tried:
psql template1
begin;
select * from pg_class;
... got stuff ...
select * from aaa;
ERROR: relation zzz does not exist
select * from pg_class;
ERROR: current transaction is aborted
Should psql run every statement in a nested
In 8.0 beta 1 I just tried:
psql template1
begin;
select * from pg_class;
... got stuff ...
select * from aaa;
ERROR: relation zzz does not exist
select * from pg_class;
ERROR: current transaction is aborted
Should psql run every
At 01:47 AM 12/08/2004, Tom Lane wrote:
It might be reasonable to offer that behavior as an option, but I think
I'd only want it on for interactive input.
My preference would be for something like:
set savepoint_per_statement=true
then interactive scripts could choose to use either feature.
Should psql run every statement in a nested transaction and only rollback
that TX?
psql is designed to follow the same logical statement progression as any
other connection to the database. Your suggestion could muck up sql
scripts piped through it to the database.
The other objection is
26 matches
Mail list logo
