Thomas Munro <thomas.mu...@enterprisedb.com> writes:
> On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I've not looked at the test case to see if this is exactly what's
>> going wrong, but it's pretty easy to see how there might be a problem:
>> consider a STABLE user-defined function that does a SELECT from a foreign
>> table. If that function call gets pushed down into a parallel worker
>> then it would fail as described.
> I thought user defined functions were not a problem since it's the
> user's responsibility to declare functions' parallel safety correctly.
> The manual says: "In general, if a function is labeled as being safe
> when it is restricted or unsafe, or if it is labeled as being
> restricted when it is in fact unsafe, it may throw errors or produce
> wrong answers when used in a parallel query"[1].
Hm. I'm not terribly happy with this its-the-users-problem approach to
things, mainly because I have little confidence that somebody couldn't
figure out a security exploit based on it.
> The case of a plain old SELECT (as seen in the failing regression
> test) is definitely a problem though and FDW access there needs to be
> detected automatically.
Yes, the problem we're actually seeing in that regression test is not
dependent on a function wrapper.
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
