This patch hasn't applied for quite some time, has been waiting on author since
December, and the thread has stalled. I'm marking this Returned with Feedback
for now, please feel free to resubmit to a future CF when there is renewed
interest in working on this.
--
Daniel Gustafsson
On Fri, Mar 24, 2023 at 2:16 PM Corey Huinker
wrote:
>
>
> On Fri, Mar 24, 2023 at 11:07 AM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
>
>> On 20.03.23 19:31, Greg Stark wrote:
>> > So I took a look at this patch. The conflict is with 2fe3bdbd691
>> > committed by Peter
On Fri, Mar 24, 2023 at 11:07 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 20.03.23 19:31, Greg Stark wrote:
> > So I took a look at this patch. The conflict is with 2fe3bdbd691
> > committed by Peter Eisentraut which added error checks for pipes.
> > Afaics the behaviour
On 20.03.23 19:31, Greg Stark wrote:
So I took a look at this patch. The conflict is with 2fe3bdbd691
committed by Peter Eisentraut which added error checks for pipes.
Afaics the behaviour is now for pipe commands returning non-zero to
cause an error*always* regardless of the setting of
On Mon, 20 Mar 2023 at 14:34, Gregory Stark (as CFM)
wrote:
>
> Pruning bouncing email address -- please respond from this point in
> thread, not previous messages.
Oh for heaven's sake. Trying again to prune bouncing email address.
Please respond from *here* on the thread Sorry
--
Pruning bouncing email address -- please respond from this point in
thread, not previous messages.
--
Gregory Stark
As Commitfest Manager
So I took a look at this patch. The conflict is with 2fe3bdbd691
committed by Peter Eisentraut which added error checks for pipes.
Afaics the behaviour is now for pipe commands returning non-zero to
cause an error *always* regardless of the setting of ON_ERROR_STOP.
I'm not entirely sure that's
On 16/02/2023 20:33, Andreas 'ads' Scherbaum wrote:
On 23/11/2022 00:16, Matheus Alcantara wrote:
--- Original Message ---
On Tuesday, November 22nd, 2022 at 20:10, bt22nakamorit
wrote:
There was a mistake in the error message for \! so I updated the patch.
Best,
Tatsuhiro
On 23/11/2022 00:16, Matheus Alcantara wrote:
--- Original Message ---
On Tuesday, November 22nd, 2022 at 20:10, bt22nakamorit
wrote:
There was a mistake in the error message for \! so I updated the patch.
Best,
Tatsuhiro Nakamori
Hi
I was checking your patch and seems that it
On 2022-10-12 2:13 a.m., bt22nakamorit wrote:
There was a mistake in the error message for \! so I updated the patch.
Tried to apply this patch to the master branch, but got the error like
below.
$ git apply --check patch-view.diff
error: patch failed: src/bin/psql/command.c:2693
error:
On Tue, Nov 22, 2022 at 6:16 PM Matheus Alcantara wrote:
> --- Original Message ---
> On Tuesday, November 22nd, 2022 at 20:10, bt22nakamorit <
> bt22nakamo...@oss.nttdata.com> wrote:
>
>
> > There was a mistake in the error message for \! so I updated the patch.
> >
> > Best,
> >
--- Original Message ---
On Tuesday, November 22nd, 2022 at 20:10, bt22nakamorit
wrote:
> There was a mistake in the error message for \! so I updated the patch.
>
> Best,
> Tatsuhiro Nakamori
Hi
I was checking your patch and seems that it failed to be applied into the
master
>
> I think it'd be a lot better to expose the script status to psql.
> (without having to write "foo; echo status=$?").
>
I agree, and I hacked up a proof of concept, but started another thread at
On Fri, Sep 16, 2022 at 03:55:33PM +0900, bt22nakamorit wrote:
> Hi,
>
> """\set ON_ERROR_STOP on""" stops any subsequent incoming query that comes
> after an error of an SQL, but does not stop after a shell script ran by
> """\! """ returning values other than 0, -1, or 127, which
> suggests a
There was a mistake in the error message for \! so I updated the patch.
Best,
Tatsuhiro Nakamoridiff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 9494f28063..82febf0ace 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -4143,7
2022-10-07 17:16 Fujii Masao wrote:
The patch failed to be applied into the master cleanly. Could you
rebase it?
patching file src/bin/psql/common.c
Hunk #1 succeeded at 94 (offset 4 lines).
Hunk #2 succeeded at 104 (offset 4 lines).
Hunk #3 succeeded at 133 (offset 4 lines).
Hunk #4 succeeded
On 2022/09/30 16:54, bt22nakamorit wrote:
2022-09-21 11:45 に Fujii Masao wrote:
We can execute the shell commands via psql in various ways
other than \! meta-command. For example,
* `command`
* \g | command
* \gx | command
* \o | command
* \w | command
* \copy ... program 'command'
2022-09-21 11:45 に Fujii Masao wrote:
We can execute the shell commands via psql in various ways
other than \! meta-command. For example,
* `command`
* \g | command
* \gx | command
* \o | command
* \w | command
* \copy ... program 'command'
ON_ERROR_STOP should handle not only \! but also all
At Thu, 29 Sep 2022 12:35:04 +0900 (JST), Kyotaro Horiguchi
wrote in
> > Thank you for the feedback!
> > I agree that the messages should be more clear.
> > \\!: command was not executed
> > \\!: command failed
> > Would these two messages be enough to describe the two cases?
>
> FWIW, I would
At Thu, 29 Sep 2022 11:29:40 +0900, bt22nakamorit
wrote in
> 2022-09-28 21:49 に torikoshia さんは書きました:
> >>if (result == 127 || result == -1)
> >>{
> >>pg_log_error("\\!: failed");
> >>return false;
> >>}
> >>else if (result != 0) {
> >>
2022-09-28 21:49 に torikoshia さんは書きました:
if (result == 127 || result == -1)
{
pg_log_error("\\!: failed");
return false;
}
else if (result != 0) {
pg_log_error("command failed");
return false;
Since it would be hard to understand the cause of failures
On 2022-09-20 15:15, bt22nakamorit wrote:
I edited the documentation for ON_ERROR_STOP.
Any other suggestions?
Thanks for the patch!
if (result == 127 || result == -1)
{
pg_log_error("\\!: failed");
return false;
}
else if (result != 0) {
Fujii Masao:
One concern about this patch is that some applications already depend on
the current behavior of ON_ERROR_STOP, i.e., psql doesn't stop even when
the shell command returns non-zero exit code. If so, we might need to
extend ON_ERROR_STOP so that it accepts the following setting
At Wed, 21 Sep 2022 11:45:07 +0900, Fujii Masao
wrote in
>
>
> On 2022/09/20 15:15, bt22nakamorit wrote:
> I thought that this action is rather unexpected since, based on the
> word """ON_ERROR_STOP""", ones may expect that failures of shell
> scripts should halt the incoming
On 2022/09/20 15:15, bt22nakamorit wrote:
I thought that this action is rather unexpected since, based on the
word """ON_ERROR_STOP""", ones may expect that failures of shell
scripts should halt the incoming instructions as well.
One clear solution is to let failures of shell script stop
2022-09-17 09:44 に bt22nakamorit さんは書きました:
2022-09-16 17:30 に Kyotaro Horiguchi さんは書きました:
At Fri, 16 Sep 2022 15:55:33 +0900, bt22nakamorit
wrote in
Hi,
"""\set ON_ERROR_STOP on""" stops any subsequent incoming query that
comes after an error of an SQL, but does not stop after a shell
2022-09-16 17:30 に Kyotaro Horiguchi さんは書きました:
At Fri, 16 Sep 2022 15:55:33 +0900, bt22nakamorit
wrote in
Hi,
"""\set ON_ERROR_STOP on""" stops any subsequent incoming query that
comes after an error of an SQL, but does not stop after a shell script
ran by """\! """ returning values other
At Fri, 16 Sep 2022 15:55:33 +0900, bt22nakamorit
wrote in
> Hi,
>
> """\set ON_ERROR_STOP on""" stops any subsequent incoming query that
> comes after an error of an SQL, but does not stop after a shell script
> ran by """\! """ returning values other than 0, -1, or
> 127, which suggests a
Hi,
"""\set ON_ERROR_STOP on""" stops any subsequent incoming query that
comes after an error of an SQL, but does not stop after a shell script
ran by """\! """ returning values other than 0, -1, or
127, which suggests a failure in the result of the shell script.
For example, suppose that
29 matches
Mail list logo
