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 |
Message-ID: | 1929340.1661531738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
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" |