Jeremy Schneider wrote: > Survey for the user community here on the pgsql-general list: it would > be great if lots of people could chime in by answering two questions > about your very own production environment: > > question 1) are you worried about scripts in your production environment > where damage could be caused by a different default in a future new > major version of postgresql? (not aborting transactions in interactive > mode when syntax errors occur) No. Any production scripts would be a single transaction. I think anything else is a disaster waiting to happen (and waiting for me to clean up afterwards). > question 2) do you think the increased user-friendliness of changing > this default behavior would be worthwhile for specific users in your > organization who use postgresql? (including both yourself and others > you know of) No. In fact, I think aborting on error is more user-friendly than not doing so. I often send ad hoc sql to psql via vim key bindings. I think that counts as interactive from psql's point of view. The only problem I have with that is when I mistyped "begin transaction;" (or forgot the semi colon) and so an error half way through doesn't result in a full rollback. But I don't see what can be done about that (other than automating the insertion of "begin transaction;" and "commit transaction;" in my ad hoc sql vim buffers). What might be actually user-friendly is the ability, after such an error, of being able to edit the contents of the failed statement/transaction in the interactive session in an editor to fix the typo. But that's for real interactive use where stdin is a pty. That way, you wouldn't have to retype or copy and paste the good bits. That might already be possible. Yes, it's "\e". And it works after an error, bringing up the erroroneous sql in an editor, and it executes it when you save and exit the editor. I think that's probably what you want and it's already there. But it only edits the last statement, not the whole transaction. It might not be exactly what you need. > As someone working at a large company with an aweful lot of PostgreSQL, > thinking of the internal production systems I'm aware of, I'd personally > vote pretty strongly in favor of changing the default. > > -Jeremy > > Jeremy Schneider > Database Engineer > Amazon Web Services cheers, raf
