pgsql: Move the extern declaration for ExceptionalCondition into c.h.

2018-02-14 Thread Tom Lane
Move the extern declaration for ExceptionalCondition into c.h. This is the logical conclusion of our decision to support Assert() in both frontend and backend code: it should be possible to use that after including just c.h. But as things were arranged before, if you wanted to use Assert() in cod

pgsql: Revert "Stabilize output of new regression test case".

2018-02-14 Thread Tom Lane
Revert "Stabilize output of new regression test case". This effectively reverts commit 9edc97b71 (although the test is now in a different place and has different contents). We don't need that hack anymore, because since commit 4b93f5799, this test case no longer throws an error and so there's no

pgsql: Stabilize new plpgsql_record regression tests.

2018-02-14 Thread Tom Lane
Stabilize new plpgsql_record regression tests. The buildfarm's CLOBBER_CACHE_ALWAYS animals aren't happy with some of the test cases added in commit 4b93f5799. There are two different problems: * In two places, a different CONTEXT stack is shown because the error is detected in a different place

Re: pgsql: Use new overflow aware integer operations.

2018-02-14 Thread Tom Lane
Andres Freund writes: >> Yea, that works for me. I wonder if we should choose an absurd sentinel >> value to prevent code from relying on one? 0xbeef or such. Unless >> somebody protests soon-ish I'll make it so. > Pushed that way (with 0x5EED as the value, seems more appropriate ;)). LGTM,

pgsql: Return implementation defined value if pg_$op_s$bit_overflow ove

2018-02-14 Thread Andres Freund
Return implementation defined value if pg_$op_s$bit_overflow overflows. Some older compilers otherwise sometimes complain about undefined values, even though the return value should not be used in the overflow case. We assume that any decent compiler will optimize away the unnecessary assignment

Re: pgsql: Use new overflow aware integer operations.

2018-02-14 Thread Andres Freund
On 2017-12-29 12:21:54 -0800, Andres Freund wrote: > On 2017-12-27 17:59:26 -0500, Tom Lane wrote: > > #if defined(HAVE__BUILTIN_OP_OVERFLOW) > > return __builtin_add_overflow(a, b, result); > > #else > > int32 res = (int32) a + (int32) b; > > > > if (res > PG_INT16_MAX ||

pgsql: Silence assorted "variable may be used uninitialized" warnings.

2018-02-14 Thread Tom Lane
Silence assorted "variable may be used uninitialized" warnings. All of these are false positives, but in each case a fair amount of analysis is needed to see that, and it's not too surprising that not all compilers are smart enough. (In particular, in the logtape.c case, a compiler lacking the kn

pgsql: Add an assertion that we don't pass NULL to snprintf("%s").

2018-02-14 Thread Tom Lane
Add an assertion that we don't pass NULL to snprintf("%s"). Per commit e748e902d, we appear to have little or no coverage in the buildfarm of machines that will dump core when asked to printf a null string pointer. Let's try to improve that situation by adding an assertion that will make src/port

pgsql: Fix broken logic for reporting PL/Python function names in errco

2018-02-14 Thread Tom Lane
Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost o

pgsql: Fix broken logic for reporting PL/Python function names in errco

2018-02-14 Thread Tom Lane
Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost o

pgsql: Fix broken logic for reporting PL/Python function names in errco

2018-02-14 Thread Tom Lane
Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost o

pgsql: Fix broken logic for reporting PL/Python function names in errco

2018-02-14 Thread Tom Lane
Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost o

pgsql: Fix broken logic for reporting PL/Python function names in errco

2018-02-14 Thread Tom Lane
Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost o

pgsql: Fix broken logic for reporting PL/Python function names in errco

2018-02-14 Thread Tom Lane
Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost o