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
