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.
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
update...
...more st
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
>
24 matches
Mail list logo
