Обсуждение: [HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
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
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
> 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