postgres_fdw hint messages

The postgres_fdw tests contain this (as amended by patch 0001):

ALTER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
ERROR: invalid option "password"
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.

Possible changes:

- Hide the hint from this particular test (done in the attached patches).

+1
I vote for this option.
Less work for future developers changes, I think worth the effort.

Anyway, in alphabetical order, it's a lot easier for users to read.

Patch attached.

regards,
Ranier Vilela

Em qui., 25 de ago. de 2022 às 14:31, Ranier Vilela <ranier.vf@gmail.com>
escreveu:

The postgres_fdw tests contain this (as amended by patch 0001):

ALTER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
ERROR: invalid option "password"
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.

Possible changes:

- Hide the hint from this particular test (done in the attached patches).

+1
I vote for this option.
Less work for future developers changes, I think worth the effort.

Anyway, in alphabetical order, it's a lot easier for users to read.

Patch attached.

Little tweak in the comments.

regards,
Ranier Vilela

On Thu, Aug 25, 2022 at 6:42 PM Peter Eisentraut <
peter.eisentraut@enterprisedb.com> wrote:

The postgres_fdw tests contain this (as amended by patch 0001):

ALTER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
ERROR: invalid option "password"
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.

Thanks Peter, for looking at that; this HINT message is growing over time.

In my opinion, we should hide the complete message in case of an invalid
option. But
try to show dependent options; for example, if someone specify "sslcrl" and
that option
require some more options, then show the HINT of that options.

Possible changes:

- Hide the hint from this particular test (done in the attached patches).

- Keep the hint, but maybe make it sorted?

- Remove all the hints like this from foreign data commands.

- Don't show the hint when there are more than N valid options.

- Do some kind of "did you mean" like we have for column names.

Thoughts?

--
Ibrar Ahmed

On Thu, Aug 25, 2022 at 9:42 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:

The postgres_fdw tests contain this (as amended by patch 0001):

ALTER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
ERROR: invalid option "password"
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.

--
Robert Haas
EDB: http://www.enterprisedb.com

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

On 25.08.22 15:42, Peter Eisentraut wrote:

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.

Possible changes:

- Remove all the hints like this from foreign data commands.

It appears that there was a strong preference toward this solution, so
that's what I implemented in the updated patch set.

(Considering the hints that are removed in the tests cases, I don't
think this loses any value. What might be useful in practice instead is
something like "the option you specified on this foreign server should
actually be specified on a user mapping or foreign table", but this
would take a fair amount of code to cover a reasonable set of cases, so
I'll leave this as a future exercise.)

On Fri, Aug 26, 2022 at 12:35:38PM -0400, Tom Lane wrote:

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.

Here is a quickly-hacked-together proof-of-concept for using Levenshtein
distances to determine which option to include in the hint. Would
something like this suffice? If so, I will work on polishing it up a bit.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Nathan Bossart <nathandbossart@gmail.com> writes:

On Fri, Aug 26, 2022 at 12:35:38PM -0400, Tom Lane wrote:

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.

Here is a quickly-hacked-together proof-of-concept for using Levenshtein
distances to determine which option to include in the hint. Would
something like this suffice? If so, I will work on polishing it up a bit.

Seems reasonable to me, but

(1) there probably needs to be some threshold of closeness, so we don't
offer "foobar" when the user wrote "huh"

(2) there are several places doing this now, and there will no doubt
be more later, so we need to try to abstract the logic so it can be
shared.

regards, tom lane

On Thu, Sep 01, 2022 at 07:08:49PM -0400, Tom Lane wrote:

(1) there probably needs to be some threshold of closeness, so we don't
offer "foobar" when the user wrote "huh"

Agreed.

(2) there are several places doing this now, and there will no doubt
be more later, so we need to try to abstract the logic so it can be
shared.

Will do.

I'm also considering checking whether the user-provided string is longer
than MAX_LEVENSHTEIN_STRLEN so that we can avoid the ERROR from
varstr_levenshtein(). Or perhaps varstr_levenshtein() could indicate that
the string is too long without ERROR-ing (e.g., by returning -1). If the
user-provided string is too long, we'd just omit the hint.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Thu, Sep 01, 2022 at 04:31:20PM -0700, Nathan Bossart wrote:

On Thu, Sep 01, 2022 at 07:08:49PM -0400, Tom Lane wrote:

(1) there probably needs to be some threshold of closeness, so we don't
offer "foobar" when the user wrote "huh"

Agreed.

(2) there are several places doing this now, and there will no doubt
be more later, so we need to try to abstract the logic so it can be
shared.

Will do.

Here is a new patch. Two notes:

* I considered whether to try to unite this new functionality with the
existing stuff in parse_relation.c, but the existing code looked a bit too
specialized.

* I chose a Levenshtein distance of 5 as the threshold of closeness for the
hint messages. This felt lenient, but it should hopefully still filter out
some of the more ridiculous suggestions. However, it's still little more
than a wild guess, so if folks think the threshold needs to be higher or
lower, I'd readily change it.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Fri, Sep 02, 2022 at 02:26:09PM -0700, Nathan Bossart wrote:

Here is a new patch. Two notes:

* I considered whether to try to unite this new functionality with the
existing stuff in parse_relation.c, but the existing code looked a bit too
specialized.

* I chose a Levenshtein distance of 5 as the threshold of closeness for the
hint messages. This felt lenient, but it should hopefully still filter out
some of the more ridiculous suggestions. However, it's still little more
than a wild guess, so if folks think the threshold needs to be higher or
lower, I'd readily change it.

Hmm. FWIW I would tend toward simplifying all this code and just drop
all the hints rather than increasing the dependency to more
levenshtein calculations in those error code paths, which is what
Peter E has posted.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

On Fri, Sep 02, 2022 at 02:26:09PM -0700, Nathan Bossart wrote:

* I chose a Levenshtein distance of 5 as the threshold of closeness for the
hint messages. This felt lenient, but it should hopefully still filter out
some of the more ridiculous suggestions. However, it's still little more
than a wild guess, so if folks think the threshold needs to be higher or
lower, I'd readily change it.

Hmm. FWIW I would tend toward simplifying all this code and just drop
all the hints rather than increasing the dependency to more
levenshtein calculations in those error code paths, which is what
Peter E has posted.

Personally I'm not a huge fan of this style of hint either. However,
people seem to like the ones for misspelled column names, so I'm
betting there will be a majority in favor of this one too.

I think the distance limit of 5 is too loose though. I see that
it accommodates examples like "passfile" for "password", which
seems great at first glance; but it also allows fundamentally
silly suggestions like "user" for "server" or "host" for "foo".
We'd need something smarter than Levenshtein if we want to offer
"passfile" for "password" without looking stupid on a whole lot
of other cases --- those words seem close, but they are close
semantically not textually.

regards, tom lane

On Fri, Sep 02, 2022 at 10:06:54PM -0400, Tom Lane wrote:

I think the distance limit of 5 is too loose though. I see that
it accommodates examples like "passfile" for "password", which
seems great at first glance; but it also allows fundamentally
silly suggestions like "user" for "server" or "host" for "foo".
We'd need something smarter than Levenshtein if we want to offer
"passfile" for "password" without looking stupid on a whole lot
of other cases --- those words seem close, but they are close
semantically not textually.

Yeah, it's really only useful for simple misspellings, but IMO even that is
rather handy.

I noticed that the parse_relation.c stuff excludes matches where more than
half the characters are different, so I added that here and lowered the
distance limit to 4. This seems to prevent the silly suggestions (e.g.,
"host" for "foo") while retaining the more believable ones (e.g.,
"passfile" for "password"), at least for the small set of examples covered
in the tests.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On 03.09.22 06:30, Nathan Bossart wrote:

On Fri, Sep 02, 2022 at 10:06:54PM -0400, Tom Lane wrote:

I think the distance limit of 5 is too loose though. I see that
it accommodates examples like "passfile" for "password", which
seems great at first glance; but it also allows fundamentally
silly suggestions like "user" for "server" or "host" for "foo".
We'd need something smarter than Levenshtein if we want to offer
"passfile" for "password" without looking stupid on a whole lot
of other cases --- those words seem close, but they are close
semantically not textually.

Yeah, it's really only useful for simple misspellings, but IMO even that is
rather handy.

I noticed that the parse_relation.c stuff excludes matches where more than
half the characters are different, so I added that here and lowered the
distance limit to 4. This seems to prevent the silly suggestions (e.g.,
"host" for "foo") while retaining the more believable ones (e.g.,
"passfile" for "password"), at least for the small set of examples covered
in the tests.

I think this code is compact enough and the hints it produces are
reasonable, so I think we could go with it.

I notice that for column misspellings, the hint is phrased "Perhaps you
meant X." whereas here we have "Did you mean X?". Let's make that uniform.

On Tue, Sep 13, 2022 at 08:32:43AM +0200, Peter Eisentraut wrote:

I notice that for column misspellings, the hint is phrased "Perhaps you
meant X." whereas here we have "Did you mean X?". Let's make that uniform.

Good point. I attached a new version of the patch that uses the column
phrasing. I wasn't sure whether "reference" was the right word to use in
this context, but I used it for now for consistency with the column hints.
I think "specify" or "use" would work as well.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On 13.09.22 21:02, Nathan Bossart wrote:

On Tue, Sep 13, 2022 at 08:32:43AM +0200, Peter Eisentraut wrote:

I notice that for column misspellings, the hint is phrased "Perhaps you
meant X." whereas here we have "Did you mean X?". Let's make that uniform.

Good point. I attached a new version of the patch that uses the column
phrasing. I wasn't sure whether "reference" was the right word to use in
this context, but I used it for now for consistency with the column hints.
I think "specify" or "use" would work as well.

I don't think we need a verb there at all. I committed it without a verb.

On Fri, Sep 16, 2022 at 03:54:53PM +0200, Peter Eisentraut wrote:

I don't think we need a verb there at all. I committed it without a verb.

Thanks!

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com