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