Re: postgres_fdw versus regconfig and similar constants

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 16, 2022 at 1:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 0002 tightens deparse.c's rules to only consider an OID alias constant
>> as shippable if the object it refers to is shippable. This seems
>> obvious in hindsight; I wonder how come we've not realized it before?
>> However, this has one rather nasty problem for regconfig in particular:
>> with our standard shippability rules none of the built-in text search
>> configurations would be treated as shippable, because initdb gives them
>> non-fixed OIDs above 9999. That seems like a performance hit we don't
>> want to take. In the attached, I hacked around that by making a special
>> exception for OIDs up to 16383, but that seems like a fairly ugly kluge.
>> Anybody have a better idea?

> No. It feels to me like there are not likely to be any really
> satisfying answers here.

Yeah. Hearing no better ideas from anyone else either, pushed that way.

I noted one interesting factoid while trying to make a test case for the
missing-schema-qualification issue. I thought of making a foreign table
that maps to pg_class and checking what is shipped for

select oid, relname from remote_pg_class where oid =
'information_schema.key_column_usage'::regclass;

(In hindsight, this wouldn't have worked anyway after patch 0002,
because that OID would have been above 9999.) But what I got was

Foreign Scan on public.remote_pg_class (cost=100.00..121.21 rows=4 width=68)
Output: oid, relname
Remote SQL: SELECT oid, relname FROM pg_catalog.pg_class WHERE ((oid = 13527::oid))

The reason for that is that the constant is smashed to type OID so hard
that we can no longer tell that it ever was regclass, thus there's no
hope of deparsing it in a more-symbolic fashion. I'm not sure if there's
anything we could do about that that wouldn't break more things than
it fixes (e.g. by making things that should look equal() not be so).
But anyway, this effect may help explain the lack of previous complaints
in this area. regconfig arguments to text search functions might be
pretty nearly the only realistic use-case for shipping symbolic reg*
values to the remote.

regards, tom lane