Re: postgres_fdw hint messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-09-03 02:06:54
Message-ID: 1267654.1662170814@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-09-03 03:03:57 Re: build remaining Flex files standalone
Previous Message Peter Geoghegan 2022-09-03 01:51:27 Re: Backpatching nbtree VACUUM (page deletion) hardening