-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 ...
...
At 12:28 AM 27/04/2005, Tom Lane wrote:
Can you show a plausible use-case for such a thing?
A not-uncommon case in other DBs is to handle insert/update code where
insert is the most likely result. Not sure if this is relevant to scripts:
Begin;
...do stuff...
insert into
trap duplicate index
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
On Mon, 25 Apr 2005, Bruce Momjian wrote:
Tom Lane wrote:
...
I think though that we ought to first consider the question of whether
we *want* this functionality. On reflection I'm fairly nervous about
the idea of actually deleting anything during startup --- seems like a
good recipe for turning
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 Tue, 26 Apr 2005, Heikki Linnakangas wrote:
On Mon, 25 Apr 2005, Bruce Momjian wrote:
...
I guess I am happy with just reporting during startup like the patch
does now.
Ok. I'll fix the design issues Tom addressed earlier, add documentation, and
resubmit.
Here you go.
The new functionality is
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
Heikki Linnakangas [EMAIL PROTECTED] writes:
I feel that crashes that leaves behind stale files are rare.
Indeed, and getting more so all the time ... which makes me question
the value of doing anything about this at all.
regards, tom lane
17 matches
Mail list logo
