From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: postgres_fdw hint messages
In-reply-to: 
 <CA+TgmoY+BuSZm-Fbxx5zC6SuML=2F9YvaYuzVAJ=XyE65BnchQ@mail.gmail.com>
References: <b1f9f399-3a1a-b554-283f-4ae7f34608e2@enterprisedb.com>
 <CA+TgmoY+BuSZm-Fbxx5zC6SuML=2F9YvaYuzVAJ=XyE65BnchQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 26 Aug 2022 12:26:18 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1929339.1661531738.1@sss.pgh.pa.us>
Date: Fri, 26 Aug 2022 12:35:38 -0400
Message-ID: <1929340.1661531738@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1929340.1661531738%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 25, 2022 at 9:42 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> HINT:  Valid options in this context are: service, passfile,
>> channel_binding, connect_timeout, dbname, host, hostaddr, port, options,
>> application_name, keepalives, keepalives_idle, keepalives_interval,
>> keepalives_count, tcp_user_timeout, sslmode, sslcompression, sslcert,
>> sslkey, sslrootcert, sslcrl, sslcrldir, sslsni, requirepeer,
>> ssl_min_protocol_version, ssl_max_protocol_version, gssencmode,
>> krbsrvname, gsslib, target_session_attrs, use_remote_estimate,
>> fdw_startup_cost, fdw_tuple_cost, extensions, updatable, truncatable,
>> fetch_size, batch_size, async_capable, parallel_commit, keep_connections
>> 
>> This annoys developers who are working on libpq connection options,
>> because any option added, removed, or changed causes this test to need
>> to be updated.
>> 
>> It's also questionable how useful this hint is in its current form,
>> considering how long it is and that the options are in an
>> implementation-dependent order.

> I think the place to list the legal options is in the documentation,
> not the HINT.

I think listing them in a hint is reasonable as long as the hint doesn't
get longer than a line or two.  This one is entirely out of hand, so
I agree with just dropping it.

Note that there is essentially identical code in dblink, file_fdw,
and backend/foreign/foreign.c.  Do we want to nuke them all?  Or
maybe make a policy decision to suppress such HINTs when there are
more than ~10 matches?  (The latter policy would likely eventually
end by always suppressing everything...)

Peter also mentioned the possibility of "did you mean" with a closest
match offered.  That seems like a reasonable idea if someone
is motivated to create the code, which I'm not.

I vote for just dropping all these hints for now, while leaving the
door open for anyone who wants to write closest-match-offering code.

			regards, tom lane