Re: [HACKERS] document and use SPI_result_code_string()

2017-10-04 Thread Peter Eisentraut
On 10/2/17 03:28, Daniel Gustafsson wrote:
>> On 06 Sep 2017, at 14:25, Tom Lane  wrote:
>>
>> 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()

2017-10-02 Thread Daniel Gustafsson
> On 06 Sep 2017, at 14:25, Tom Lane  wrote:
> 
> 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()

2017-09-06 Thread Tom Lane
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.

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()

2017-09-06 Thread Michael Paquier
On Thu, Aug 31, 2017 at 11:23 AM, Peter Eisentraut
 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