On 11/4/16 4:04 AM, Oleksandr Shulgin wrote:
The psql process even exits with an error code 2, which might be not that expected. We could stop reading the file and reset connection afterwards, but this is probably not that easy to achieve (think of nested \i calls).
Well, if you stop reading from the file then I don't think more \i's will matter, no? I'd certainly like to see improvement here, because the difference in behavior with \i is annoying.
On the bigger question of how to better protect all these cases (cut & paste, etc), I think the only robust way to do that is for psql to track intended transaction status itself. With the amount of parsing it's already doing, maybe that wouldn't be that hard to add. It looks like this might require extra libpq calls to constantly check in on server status; I'm a bit surprised that result objects don't include that info.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
