Applied.
---
pgman wrote:
> pgman wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Tom Lane wrote:
> > > >> Well, that's just a matter of choosing good (ie short) names for the
> > > >> backslash commands. I
pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian 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?
> >
Tom Lane wrote:
> Bruce Momjian 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 O
Bruce Momjian 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 ON_ERROR_ROLLBACK to work in no
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
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',
-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
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 it
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 actu
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;
\end_igno
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_ig
Tom Lane wrote:
Richard Huxton 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...
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> BEGIN;
>> \begin_ignore_error
>> DROP TABLE foo;
>> \end_ignore_error
>> CREATE ...
>> ...
>> COMMIT;
> That seems awful noisy. Why not just:
>BEGIN:
>DROP TABLE foo;
>ERROR: table foo does not exist;
>CONTINUE;
>
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.
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 ...
...
COM
Richard Huxton 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. What i
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
"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-interac
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-interactiv
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 somethin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Bruce Momjian 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 follow it in non-i
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
>
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 e
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 comm
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
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 d
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
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 t
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, ple
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> I don't have a good solution, but I do think that you need to set things
> up so that an application or script must invoke the new behavior
> explicitly. Hidden defaults that silently change such behavior look
> like land mines wai
"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 go
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
-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:
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:
http://www.gtsm.com/pg/p
-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 working well enough
at the moment. So, please try to break this patch:
h
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 ta
-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 clien
Alvaro Herrera wrote:
>Michael Paesold wrote:
Alvaro suggested to implement such a function. It is not there yet. I
think
you would have to access the sub xact stack, but I have not looked into
that code for quite some time.
http://archives.postgresql.org/pgsql-general/2004-10/msg00370.php
The on
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 in
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 yet.
-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?
I looked over the patch from Micha
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
> f
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:
http://archives
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
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 t
-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 u
48 matches
Mail list logo
