Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ph
At 01:32 AM 16/08/2004, Tom Lane wrote:
It'd be substantially *more* helpful if it reported the failing command.
They are two different problems; the TOC entry is important for any
multiline command or to rerun the command easily later.
Whereas displaying the failed SQL command is a matter of fi
Philip Warner <[EMAIL PROTECTED]> writes:
> Attached patch sets client_min_messages as above and gives some
> context to errors messages, eg:
> pg_restore: [archiver (db)] Error from TOC Entry 19; 1255 16438403 FUNCTION foo() pjw
> pg_restore: [archiver (db)] could not execute query: ERROR: no s
At 02:32 PM 12/08/2004, Philip Warner wrote:
>At 01:27 PM 12/08/2004, Bruce Momjian wrote:
>Set client_min_messages to WARNING?
>
>Sounds like a plan.
Attached patch sets client_min_messages as above and gives some
context to errors messages, eg:
pg_restore: [archiver (db)] Error from TOC Entry
At 01:27 PM 12/08/2004, Bruce Momjian wrote:
Set client_min_messages to WARNING?
Sounds like a plan.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498)
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > At 02:31 AM 12/08/2004, Tom Lane wrote:
> >> result of
> >> considerable experience that says die_on_errors is NOT the right
> >> behavior for pg_restore.
>
> > Can you point me to examples?
>
> Trawl the archives for pg_restore comp
Philip Warner <[EMAIL PROTECTED]> writes:
> At 02:31 AM 12/08/2004, Tom Lane wrote:
>> result of
>> considerable experience that says die_on_errors is NOT the right
>> behavior for pg_restore.
> Can you point me to examples?
Trawl the archives for pg_restore complaints ... but basically the point
At 02:31 AM 12/08/2004, Tom Lane wrote:
result of
considerable experience that says die_on_errors is NOT the right
behavior for pg_restore.
Can you point me to examples? Is it just an expectation problem that could
be fixed with better docs? I tend to expect scripts to die when they
encounter an
At 02:33 AM 12/08/2004, Fabien COELHO wrote:
Maybe the time has come;-)
Sounds good to me. We've had the original behaviour since 7.1, I can
understand there may be a desire to make it consistent with the
carr-on-regardless behaviour of psql, but changing it in one release
without the ability to
Philip Warner <[EMAIL PROTECTED]> writes:
> The default setting of 'false' is a pain. And the fact it can't be changed
> by an option is even more of a pain. Any objections to adding an option to
> pg_restore to allow 'die_on_errors' to be set to 'true'?
If you like, but that change was delibera
Dear Philip,
> The default setting of 'false' is a pain. And the fact it can't be
> changed by an option is even more of a pain. Any objections to adding an
> option to pg_restore to allow 'die_on_errors' to be set to 'true'?
If I remember correctly, I'm the one who implemented that ignore error
The default setting of 'false' is a pain. And the fact it can't be changed
by an option is even more of a pain. Any objections to adding an option to
pg_restore to allow 'die_on_errors' to be set to 'true'?
-D(?) --die-on-errors
---
12 matches
Mail list logo
