From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: error handling in pqRowProcessor broken |
Date: | 2022-04-19 19:16:05 |
Message-ID: | 2617038.1650395765@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> I find that this doesn't work anymore. If you set *errmsgp = "some
> message" and return 0, then psql will just print a result set with zero
> rows.
Ah, I see the problem: a few places in fe-protocol3 didn't get the memo
that conn->error_result represents a "pending" PGresult that hasn't
been constructed yet. The attached fixes it for me --- can you try it
on whatever test case led you to this?
> (Even before the above commit, the handling of the returned message was
> a bit weird: The error output was just the message string, without any
> prefix like "ERROR:".)
libpq's always acted that way for internally-generated messages.
Most of them are so rare that we're probably not used to seeing 'em.
Perhaps there's a case for making it more verbose, but right now
doesn't seem like the time to undertake that.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-libpq-error-cases.patch | text/x-diff | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Zhang | 2022-04-19 19:54:49 | Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit |
Previous Message | Daniel Gustafsson | 2022-04-19 19:14:46 | Re: Readd use of TAP subtests |