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
