On Wed, Jul 9, 2014 at 8:08 AM, Greg Stark <stark@mit.edu> wrote:
> A simple rule is easier for users to understand as well as to code. I
> would humbly suggest the following: take all the unqualified column
> names, downcase them, check which ones match most closely the
> unmatched column. Show the top 3 matches if they're within some
> arbitrary distance.
That's harder than it sounds. You need even more translatable strings
for variant ereports(). I don't think that an easy to understand rule
is necessarily of much value - I'm already charging half price for
deletion because I found representative errors more useful in certain
cases by doing so. I think we want something that displays the most
useful suggestion as often as is practically possible, and does not
display unhelpful suggestions to the extent that it's practical to
avoid them. Plus, as I mentioned, I'm keen to avoid adding more stuff
to scanRTEForColumn() than I already have.
> Honestly the current logic and the previous logic both seemed
> reasonable to me. They're not going to be perfect in every case so
> anything that comes up some some suggestions is fine.
I think that the most recent revision is somewhat better due to the
feedback of Tom and Robert. I didn't feel as strongly as they did
about erring on the side of not showing a HINT, but I think the most
recent revision is a good compromise. But yes, at this point we're
certainly chasing diminishing returns. There are almost any number of
variants of this basic idea that could be suggested.
--
Peter Geoghegan