Re: BUG #17161: Assert failed on opening a relation that exists in two schemas via the LANGUAGE SQL function

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> My initial conclusion was incorrect. Duplicate relation is not needed in
> the second schema. It's sufficient to just change search_path to another
> schema:

Actually, you don't need to mess with search_path at all: inlining of
set-returning SQL functions just plain does not work, if they are
new-style. The reason is that we forgot to apply AcquireRewriteLocks
in that code path. That leads to the assertion failure you show here.
Even without that, we risk problems with JOINs on dropped columns, which
is another thing that AcquireRewriteLocks is charged with cleaning up.

The regression tests fail to show this problem because, while they do
test inlining of a new-style SRF, the solitary test case contains no
relation references.

I looked around at other places that consult prosqlbody, and saw
that the only one that accounts for the lock issue is init_sql_fcache.
fmgr_sql_validator and print_function_sqlbody are also being cavalier
about this, and I doubt that either one of them is really safe.
(You could maybe argue that print_function_sqlbody doesn't need locks,
but in view of the dropped-JOIN-column issue, I don't think I believe
it. Likewise in fmgr_sql_validator, which wasn't applying the rewriter
at all, which I doubt is OK considering the older code path does it.)

Proposed patch attached.

regards, tom lane