Re: [HACKERS] document and use SPI_result_code_string()
On 10/2/17 03:28, Daniel Gustafsson wrote: >> On 06 Sep 2017, at 14:25, Tom Lanewrote: >> >> Michael Paquier 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
Re: [HACKERS] document and use SPI_result_code_string()
> On 06 Sep 2017, at 14:25, Tom Lanewrote: > > Michael Paquier 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
Re: [HACKERS] document and use SPI_result_code_string()
Michael Paquierwrites: > 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
Re: [HACKERS] document and use SPI_result_code_string()
On Thu, Aug 31, 2017 at 11:23 AM, Peter Eisentrautwrote: > 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