document and use SPI_result_code_string()
A lot of semi-internal code just prints out numeric SPI error codes,
which is not very helpful. We already have an API function
SPI_result_code_string() to convert the codes to a string, so here is a
patch to make more use of that and also document it for external use.
Also included are two patches to clarify that some RI error handling
code that I encountered at the same time.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Move-SPI-error-reporting-out-of-ri_ReportViolation.patchtext/plain; charset=UTF-8; name=0001-Move-SPI-error-reporting-out-of-ri_ReportViolation.patch; x-mac-creator=0; x-mac-type=0Download+11-19
0002-Add-attribute-noreturn.patchtext/plain; charset=UTF-8; name=0002-Add-attribute-noreturn.patch; x-mac-creator=0; x-mac-type=0Download+1-2
0003-Document-and-use-SPI_result_code_string.patchtext/plain; charset=UTF-8; name=0003-Document-and-use-SPI_result_code_string.patch; x-mac-creator=0; x-mac-type=0Download+63-11
On Thu, Aug 31, 2017 at 11:23 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
A lot of semi-internal code just prints out numeric SPI error codes,
which is not very helpful. We already have an API function
SPI_result_code_string() to convert the codes to a string, so here is a
patch to make more use of that and also document it for external use.Also included are two patches to clarify that some RI error handling
code that I encountered at the same time.
Those are simple things. Agreed for 0001 to untangle things.
Fine for 0002. This reminds me of LockGXact and RemoveGXact in
twophase.c, as well as _hash_squeezebucket that have some code paths
that cannot return... Any thoughts about having some kind of
PG_NOTREACHED defined to 0 which could be put in an assertion?
+1 for 0003. There are other undocumented functions available to users:
- SPI_plan_is_valid
- SPI_execute_snapshot
- SPI_plan_get_plan_sources
- SPI_plan_get_cached_plan
- SPI_datumTransfer
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
Fine for 0002. This reminds me of LockGXact and RemoveGXact in
twophase.c, as well as _hash_squeezebucket that have some code paths
that cannot return... Any thoughts about having some kind of
PG_NOTREACHED defined to 0 which could be put in an assertion?
Generally we just do "Assert(false)", maybe with "not reached" in a
comment. I don't feel a strong need to invent a new way to do that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06 Sep 2017, at 14:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
Fine for 0002. This reminds me of LockGXact and RemoveGXact in
twophase.c, as well as _hash_squeezebucket that have some code paths
that cannot return... Any thoughts about having some kind of
PG_NOTREACHED defined to 0 which could be put in an assertion?Generally we just do "Assert(false)", maybe with "not reached" in a
comment. I don't feel a strong need to invent a new way to do that.
Moving this to the next commitfest and bumping status to Ready for committer
based on the discussion in this thread.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/2/17 03:28, Daniel Gustafsson wrote:
On 06 Sep 2017, at 14:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
Fine for 0002. This reminds me of LockGXact and RemoveGXact in
twophase.c, as well as _hash_squeezebucket that have some code paths
that cannot return... Any thoughts about having some kind of
PG_NOTREACHED defined to 0 which could be put in an assertion?Generally we just do "Assert(false)", maybe with "not reached" in a
comment. I don't feel a strong need to invent a new way to do that.Moving this to the next commitfest and bumping status to Ready for committer
based on the discussion in this thread.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers