Re: Query execution failure

From: Joe Conway <mail(at)joeconway(dot)com>
To: Pete Storer <Pete(dot)Storer(at)sas(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Query execution failure
Date: 2023-01-30 20:04:58
Message-ID: 1f2cbcbd-25fa-9da0-ae0d-a4783aad966a@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 1/30/23 13:24, Pete Storer wrote:
> Makes sense - but I'm using the PG substring function here.
>
> LEFT OUTER JOIN main.ship_event se ON (se.ship_event_nm = substring(dp.shipevent from 6 for 5))
>
> In this case, the dp.shipevent is in the fdw-accessed MySql table. Shouldn't that force the sort to be local?

Looking at the mysql-fdw source (which looks pretty much the same as
postgres-fdw at first glance):
8<-------------
/* We don't support cases where there are any SRFs in the targetlist */
if (parse->hasTargetSRFs)
return;
8<-------------

Based on that, perhaps a kluge (and completely untested) workaround is to:
1/ create an SRF that returns one column, one row constant
2/ add the SRF to your targetlist

The SRF likely needs to be plpgsql to avoid inlining, maybe something like:
8<-------------
CREATE OR REPLACE FUNCTION theanswer() RETURNS setof int as $$
BEGIN
RETURN NEXT 42;
END;
$$ LANGUAGE plpgsql;
8<-------------

HTH,
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-01-30 22:53:33 Re: BUG #17502: View based on window functions returns wrong results when queried
Previous Message Pete Storer 2023-01-30 18:24:12 RE: Query execution failure