On Sat, Nov 19, 2022 at 12:59 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sat, Nov 19, 2022 at 12:49 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>
>> Greg Stark <st...@mit.edu> writes:
>> > On Sat, 19 Nov 2022 at 14:10, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> >> Under what circumstances would it be appropriate for a script to take
>> >> it on itself to decide that? It has no way of knowing what the next -f
>> >> option is or what the user intended.
>>
>> > Presumably when they're written by the same person so the script does
>> > effectively know what the "user" intended because it's written by the
>> > same user.
>>
>> Even so, embedding that knowledge in the first script doesn't seem
>> like the sort of design we ought to encourage. It'd be better if
>> "don't run the next script if the first one fails" were directed
>> by a command-line switch or the like. I also wonder exactly how
>> this interacts with existing features like ON_ERROR_STOP.
>>
>
> vagrant@vagrant:~$ /usr/local/pgsql/bin/psql -v ON_ERROR_STOP=1 -f
> two.psql -f three.psql postgres
> psql:two.psql:1: ERROR: division by zero
> vagrant@vagrant:~$ /usr/local/pgsql/bin/psql -f two.psql -f three.psql
> postgres
> psql:two.psql:1: ERROR: division by zero
> ?column?
> ----------
> 2
> (1 row)
>
> ?column?
> ----------
> 3
> (1 row)
>
>
Sorry, forgot the \quit test:
vagrant@vagrant:~$ /usr/local/pgsql/bin/psql -v ON_ERROR_STOP=1 -f two.psql
-f three.psql postgres
?column?
----------
2
(1 row)
?column?
----------
3
(1 row)
(there is a \quit at the end of two.psql)
David J.
