Hello Tom,
Fixing the problem envolves deciding what is the right behavior, and
update the documentation and the implementation accordingly. Currently the
documentation suggests that :ERROR is about SQL error (subject to
interpretation), and the implementation is more or less consistent with
that view, but not always, as pointed out by Daniel.
FWIW, I think we should adopt the rule that :ERROR reflects any error
condition, whether server-side or client-side.
I think that everybody agrees with that.
It's unlikely that scripts would really not care about client-side
errors. Moreover, I do not think we can reliably tell the difference;
there are always going to be corner cases that are hard to classify.
Example: if we lose the server connection, is that a server-side error
or client-side? Or maybe neither, maybe the network went down.
Because of this concern, I find the idea of inventing separate
SQL_ERROR and CLIENT_ERROR variables to be a pretty terrible one.
Then the committer is right:-)
I think we'd be creating a lot of make-work and hard choices for
ourselves, to do something that most script writers won't give a
fig about. If you've got subtle error-handling logic in mind,
you shouldn't be trying to implement your app in a psql script
in the first place, IMO anyway.
Possibly. I was also thinking of debug. ISTM that SQL_ERROR is pretty
trivial to implement because we already set SQLSTATE, and SQL_ERROR is
probably something like SQLSTATE != "0000" or close to that.
It's unclear to me whether to push ahead with Daniel's existing
patch or not. It doesn't look to me like it's making things
any worse from the error-consistency standpoint than they were
already, so I'd be inclined to consider error semantics cleanup
as something to be done separately/later.
Fine.
BTW, it looks to me like the last patch is still not right as far
as when to close copystream --- won't it incorrectly close a
stream obtained from pset.copyStream?
Argh, I should have checked this point.
--
Fabien.
