| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: How to *really* quit psql? |
| Date: | 2022-11-19 19:49:37 |
| Message-ID: | 2628824.1668887377@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On Sat, 19 Nov 2022 at 14:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-11-19 19:59:01 | Re: How to *really* quit psql? |
| Previous Message | Peter Geoghegan | 2022-11-19 19:42:55 | Simplify vacuum_set_xid_limits()'s signature (minor refactoring) |