Applied.
---
pgman wrote:
pgman wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Well, that's just a matter of choosing good (ie short) names for the
backslash commands.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm finding it hard to visualize a non-interactive script making
any good use of such a setting. Without a way to test whether
you got an error or not, it would amount to an ignore errors
within transactions mode, which seems a pretty bad idea.
On Tue, 2005-04-26 at 10:28, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
To reiterate my opinion, I think the behavior should be the same
for interactive and non-interactive sessions. Not only will it
prevent nasty surprises, but unless we make a third 'setting',
there
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
\begin_ignore_error
DROP TABLE foo;
\end_ignore_error
I meant it's a lot to type ;-)
Well, that's just a matter of choosing good (ie short) names for the
backslash commands. I was trying to be clear rather than proposing
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Well, that's just a matter of choosing good (ie short) names for the
backslash commands. I was trying to be clear rather than proposing
names I would actually want to use ;-). Any suggestions?
Well, if we allowed
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Well, that's just a matter of choosing good (ie short) names for the
backslash commands. I was trying to be clear rather than proposing
names I would actually want to use ;-). Any suggestions?
Well, if we
pgman wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Well, that's just a matter of choosing good (ie short) names for the
backslash commands. I was trying to be clear rather than proposing
names I would actually want to use ;-). Any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg Sabino Mullane wrote:
To reiterate my opinion, I think the behavior should be the same
for interactive and non-interactive sessions. Not only will it
prevent nasty surprises, but unless we make a third 'setting',
there will be no way to enable this in non-interactive scripts,
which is
Michael Paesold wrote:
But people (like me for example) will want to enable this behaviour by
default. So they (me too) will put the option in .psqlrc. It is then
enabled by default. But then many of my scripts will destroy data
instead of just erroring out.
I just don't see why non-interactive
Greg Sabino Mullane [EMAIL PROTECTED] writes:
To reiterate my opinion, I think the behavior should be the same
for interactive and non-interactive sessions. Not only will it
prevent nasty surprises, but unless we make a third 'setting',
there will be no way to enable this in non-interactive
Richard Huxton wrote:
Michael Paesold wrote:
But people (like me for example) will want to enable this behaviour by
default. So they (me too) will put the option in .psqlrc. It is then
enabled by default. But then many of my scripts will destroy data
instead of just erroring out.
I just don't
Richard Huxton dev@archonet.com writes:
Michael Paesold wrote:
I just don't see why non-interactive mode does need such a switch
because there is no way to check if there was an error. So just put two
queries there and hope one will work?
DROP TABLE foo;
CREATE TABLE foo...
Unconvincing.
I would far rather see people code explicit markers around statements
whose failure can be ignored. That is, a script that needs this
behavior ought to look like
BEGIN;
\begin_ignore_error
DROP TABLE foo;
\end_ignore_error
CREATE ...
...
Philip Warner [EMAIL PROTECTED] writes:
Also, the blunder-on-regardless approach is popular in pg_dump, or so I'm
told ;-).
Sure, but pg_dump scripts don't try to execute as a single transaction.
None of this discussion applies to the behavior outside an explicit
transaction block.
Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
Michael Paesold wrote:
I just don't see why non-interactive mode does need such a switch
because there is no way to check if there was an error. So just put two
queries there and hope one will work?
DROP TABLE foo;
CREATE
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I would far rather see people code explicit markers around statements
whose failure can be ignored. That is, a script that needs this
behavior ought to look like
BEGIN;
\begin_ignore_error
DROP TABLE foo;
\end_ignore_error
CREATE
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I would far rather see people code explicit markers around statements
whose failure can be ignored. That is, a script that needs this
behavior ought to look like
BEGIN;
\begin_ignore_error
DROP TABLE foo;
Andrew Dunstan [EMAIL PROTECTED] writes:
\begin_ignore_error
DROP TABLE foo;
\end_ignore_error
I meant it's a lot to type ;-)
Well, that's just a matter of choosing good (ie short) names for the
backslash commands. I was trying to be clear rather than proposing
names I would actually want
On Apr 26, 2005, at 10:35 AM, Tom Lane wrote:
Once you've got such an infrastructure, it makes sense to allow an
interactive mode that automatically puts such things around each
statement. But I can't really see the argument for using such a
behavior in a script. Scripts are too stupid.
Would
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Finally had a chance to sit down at look at this afresh, and I'm
pretty sure I've got all the kinks worked out this time. Apologies
for not attaching, but my mail system is not
On Mon, Apr 25, 2005 at 12:34:00PM -0400, Bruce Momjian wrote:
Finally had a chance to sit down at look at this afresh, and I'm
pretty sure I've got all the kinks worked out this time. Apologies
for not attaching, but my mail system is not working well enough
at the moment. So, please try
Michael Paesold wrote:
Greg Sabino Mullane wrote:
Finally had a chance to sit down at look at this afresh, and I'm
pretty sure I've got all the kinks worked out this time. Apologies
for not attaching, but my mail system is not working well enough
at the moment. So, please try to break
Greg Sabino Mullane wrote:
* If I read the code correctly, you now don't destroy user savepoints
anymore, but on the other hand, you do not release the psql savepoint after
a user-defined savepoint is released. In other words, each time a user
creates a savepoint, one psql savepoint is
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I do think so. In it's current state, would you yourself put \reseterror in
your .psqlrc? Or even an /etc/psqlrc?
It would break all my scripts that must either succeed or fail -- now they
will produce garbage in my databases
Greg Sabino Mullane wrote:
The current way is ok for me at the moment. I still think there is a better
way (parsing statements like it's already done for
no-transaction-allowed-statements), but hey, as soon as your patch will be
applied, I can myself propose another patch to improve this.
Bruce Momjian wrote:
Michael Paesold wrote:
Some suggestions in random order:
* I think you should use PSQLexec instead of using PQexec directly.
PSQLexec
is used by all \-commands and prints out queries with -E, which is very
helpful for debugging.
-E display queries that internal
Alvaro Herrera wrote:
On Mon, Apr 25, 2005 at 12:34:00PM -0400, Bruce Momjian wrote:
Finally had a chance to sit down at look at this afresh, and I'm
pretty sure I've got all the kinks worked out this time. Apologies
for not attaching, but my mail system is not working well enough
Bruce Momjian wrote:
Greg Sabino Mullane wrote:
The SQL-Standard itself says that errors inside transactions should only
rollback the last statement, if possible. So why is that not implemented
in
PostgreSQL? What I read from past discussions here, is because it's just
unsave and
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I think everyone agrees this should only work in interactive mode. I
think the only unknown is if it should be 'on' by default in interactive
mode? Does it make sense to follow the standard in interactive mode if
we don't
Greg Sabino Mullane wrote:
Finally had a chance to sit down at look at this afresh, and I'm
pretty sure I've got all the kinks worked out this time. Apologies
for not attaching, but my mail system is not working well enough
at the moment. So, please try to break this patch:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* I think you should use PSQLexec instead of using PQexec directly. PSQLexec
is used by all \-commands and prints out queries with -E, which is very
helpful for debugging.
But these are not backslash commands, but almost directly analogous to
Greg Sabino Mullane wrote:
* You have not yet implemented a way to savely put \reseterror
in .psqlrc. I previously suggested an AUTO setting (additional
to ON/OFF) that disables \reseterror when reading from a non-tty.
So putting \reseterror AUTO in ..psqlrc would be save.
Hmm...I suppose we could
Michael Paesold [EMAIL PROTECTED] writes:
I do think so. In it's current state, would you yourself put \reseterror in
your .psqlrc? Or even an /etc/psqlrc?
It would break all my scripts that must either succeed or fail -- now they
will produce garbage in my databases when something goes
This thread has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is a patch that takes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Do you think it's better to create a server-side function or
handle that in the client? How hard would it be to implement
such a function? And what should it return? Only the name of
the current top savepoint?
I think handled on the client.
Greg Sabino Mullane wrote:
Michael Paesold wrote:
2) Implement a server-side function to get the savepoints from the server
and query that before every release.
I could not find a way to do this. Is there any interface to the list?
Alvaro suggested to implement such a function. It is not there
On Sat, Jan 29, 2005 at 01:04:36PM +0100, Michael Paesold wrote:
Greg Sabino Mullane wrote:
Michael Paesold wrote:
2) Implement a server-side function to get the savepoints from the server
and query that before every release.
I could not find a way to do this. Is there any interface to
I've attached a revised patch which fixes the problem, however I'm sure there
is a better way. Thanks to Neil for putting up with me on irc :-)
How about calling the savepoint pg_psql_savepoint instead, that way it
follows our 'don't begin things with pg_' philosophy.
Chris
Robert Treat wrote:
I've attached a revised patch which fixes the problem, however I'm sure
there
is a better way. Thanks to Neil for putting up with me on irc :-)
In September 2004 I had already sent a patch to implement this behaviour,
the patch, still in the archives, is here:
On Fri, 2005-01-28 at 04:46, Christopher Kings-Lynne wrote:
I've attached a revised patch which fixes the problem, however I'm sure
there
is a better way. Thanks to Neil for putting up with me on irc :-)
How about calling the savepoint pg_psql_savepoint instead, that way it
follows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Paesold wrote:
2) Implement a server-side function to get the savepoints from the server
and query that before every release.
I could not find a way to do this. Is there any interface to the list?
/aside
I looked over the patch from
On Tuesday 25 January 2005 22:07, Greg Sabino Mullane wrote:
Attached is a patch that takes advantage of savepoints to enable
transactions to continue even after errors in psql. The name of it
is \reseterror, and it is off by default. It's backwards compatible,
and allows things like this to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is a patch that takes advantage of savepoints to enable
transactions to continue even after errors in psql. The name of it
is \reseterror, and it is off by default. It's backwards compatible,
and allows things like this to work on 8.0 and
44 matches
Mail list logo
