Peter Eisentraut <pete...@gmx.net> writes: > AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html) > (also available through gcc, but I used clang), reports one bug, which > I traced down to this code in ruleutils.c:
> [elsewhere:] > #define ViewSelectRuleName "_RETURN" > /* > * Get the pg_rewrite tuple for the view's SELECT rule > */ > args[0] = ObjectIdGetDatum(viewoid); > args[1] = PointerGetDatum(ViewSelectRuleName); > nulls[0] = ' '; > nulls[1] = ' '; > spirc = SPI_execute_plan(plan_getviewrule, args, nulls, true, 2); Yes, the plan clearly is built expecting $2 to be of type "name", so this has been wrong since day 1. Amazing that no actual bug reports have surfaced from it. > I think the correct code is something like > args[1] = DirectFunctionCall1(namein, > CStringGetDatum(ViewSelectRuleName)); That would be OK. The more usual coding pattern is to declare a local NameData variable, namestrcpy into that, and then PointerGetDatum on the variable's address is actually correct. However, that's just micro-optimization that I don't think we care about here. > [I also think that the 2 here is wrong, probably thinking it means 2 > arguments, but it means 2 result rows, but only one is needed. But > that's unrelated to the bug.] Yes, while harmless that's clearly in error, should be zero. The other call of SPI_execute_plan in ruleutils.c has the same thinko. Please fix and back-patch. 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