On Wed, Jul 9, 2014 at 8:08 AM, Greg Stark <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
