Re: postgres_fdw hint messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw hint messages
Date: 2022-08-26 16:35:38
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Aug 25, 2022 at 9:42 AM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2022-08-26 16:36:11 Re: SQL/JSON features for v15
Previous Message Robert Haas 2022-08-26 16:33:33 Re: Letter case of "admin option"