David Geier <geidav.pg@gmail.com> writes:
> The filter clause of the query SELECT * FROM test WHERE col = 'foo' OR
> col = 'bar' is pushed down to the remote, while the filter clause of the
> semantically equivalent query SELECT * FROM test WHERE col IN ('foo',
> 'bar') is not.
> I traced this down to getExtensionOfObject() called from
> lookup_shippable(). getExtensionOfObject() doesn't recurse but only
> checks first level dependencies and only checks for extension
> dependencies. However, the IN operator takes an array of our custom data
> type as argument (type is typically prefixed with _ in pg_type). This
> array type is only dependent on our extension via the custom data type
> in two steps which postgres_fdw doesn't see. Therefore, postgres_fdw
> doesn't allow for push-down of the IN.
Hmm. It seems odd that if an extension defines a type, the type is
listed as a member of the extension but the array type is not.
That makes it look like the array type is an externally-created
thing that happens to depend on the extension, when it's actually
part of the extension. I'm surprised we've not run across other
misbehaviors traceable to that.
Of course, fixing it like that leads to needing to change the
contents of pg_depend, so it wouldn't be back-patchable. But it
seems like the best way in the long run.
regards, tom lane