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.