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
Bruce Momjian wrote:
Mark Kirkwood wrote:
Personally I favor 1), so would prefer:
enable it by default only for interactive sessions, like AUTOCOMMIT
We are going for 'off' by default and only interactive.
Sweet.
The fact that
interactive and non-interactive behavior is different is something th
Mark Kirkwood wrote:
> Bruce Momjian wrote:
> >
> > disable it by default for all sessions (current patch)
> > enable it by default only for interactive sessions, like AUTOCOMMIT
>
> These two seem like the best contenders.
>
> The choice comes down to whether we should:
>
> 1) Be like
Bruce Momjian wrote:
disable it by default for all sessions (current patch)
enable it by default only for interactive sessions, like AUTOCOMMIT
These two seem like the best contenders.
The choice comes down to whether we should:
1) Be like most other dbms's (e.g. Oracle, Firebird) + fol
enable it by default only for interactive sessions, like AUTOCOMMIT
And that is what other dbms' do.
The current version controls only interactive sessions, and is off by
default. I am willing to change that, but I need to hear from more
people on this to change it.
It's good with me.
Chris
Christopher Kings-Lynne wrote:
> > disable it by default for all sessions (current patch)
>
> That is the most backwards non-surprising solution.
>
> > enable it by default only for interactive sessions, like AUTOCOMMIT
>
> And that is what other dbms' do.
The current version controls o
disable it by default for all sessions (current patch)
That is the most backwards non-surprising solution.
enable it by default only for interactive sessions, like AUTOCOMMIT
And that is what other dbms' do.
Chris
---(end of broadcast)---
TIP 3: if
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-interative mode?
I doubt i
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-interative mode?
---
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 wi
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 will lead to data-garb
29 matches
Mail list logo
