Re: Alternative to \copy in psql modelled after \g

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
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.


> 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.


In response to


Browse pgsql-hackers by date

  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