On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver <adrian.kla...@aklaver.com> wrote:
> On 12/29/2014 09:38 AM, David Johnston wrote: > >> >> This is one of those glass half full/empty situations, where it is >> down to the eye of the beholder. I would also say this a perfect >> example of why tests are written, to see what actually happens >> versus what you think happens. >> >> >> If a user of our product needs to run a test to determine behavior then >> our documentation is flawed - which is the point I am making. >> > > Still not seeing the flaw in the documentation. ... > > >> psql does not see any error due to meta-commands or SQL as fatal - >> which is why the ON_ERROR_STOP option exists. >> > > And ON_ERROR_STOP does not change that. All it does is toggle whether psql > continues on after an error or stops processing commands. If it walks and talks like a duck...the fact that ON_ERROR_STOP makes psql halt processing means that it now treats them like it does any other fatal error. > > > >> I believe that if ON_ERROR_STOP causes an abort that the COMMIT from >> --single-transaction should not run. That is a behavior change. But >> not documenting the known and deterministic interaction between the two >> options is a bug. >> > > I am not seeing anything in the below that says an ABORT is issued: > I was using term in its non-SQL sense: to stop processing and return control to the user. > 2) the implications of \include being a client-side mechanic and thus, >> invisible to the server, is not well explained. Specifically that a >> failure to include is the equivalent of simply omitting the statement >> altogether (aside from the psql warning). i.e., if in an actual >> transaction the server will not issue the standard "error has occurred, >> you must ROLLBACK." message for any subsequent statements in the >> script. This is probably not to the level of a bug but it is related to >> the ON_ERROR_STOP bug. >> > > I could see improving the wording on this, to let the user know that > includes are on them as Viktor already determined and took action on. > > I think you have a typo somewhere here 'cause that sentence fragment (...includes and on them as) makes no sense to me. The overall complaint is that a missing \include file, without ON_ERROR_STOP, ends up being totally ignored even while in non-interactive mode. I get the benefit to that behavior in interactive mode and so being required to use ON_ERROR_STOP in script mode (which is the safest practice anyway) isn't that big a deal as long as in that mode a failure causes an immediate stop without any other SQL being sent to the server and, by extension, the session closing and effecting a rollback in the process if in --single-transaction mode just like that mode promises. I'm not sure why --single-transaction even exists TBH. The script should determine its desired transaction modes and not leave the decision up to the caller. If the script relies on all-or-nothing it should have explicit BEGIN/COMMIT statements. That said it does exist so it should play nicely with ON_ERROR_STOP. It currently does not nor is the not-nice interaction documented anywhere. David J.
