From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Subject: | Re: Alternative to \copy in psql modelled after \g |
Date: | 2019-01-25 22:44:27 |
Message-ID: | alpine.DEB.2.21.1901252337480.17261@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-01-25 23:34:17 | Re: GUC parameters accepts values in both octal and hexadecimal formats |
Previous Message | Bruce Momjian | 2019-01-25 22:38:59 | Bison state table |