Robert Haas <robertmh...@gmail.com> writes: > On Thu, Aug 25, 2022 at 9:42 AM Peter Eisentraut > <peter.eisentr...@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