Re: Doing better at HINTing an appropriate column within errorMissingColumn()

On Tue, Jul 8, 2014 at 1:42 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> That's because those two candidates come from a single RTE and have an
>> equal distance -- you'd see both suggestions if you joined two tables
>> with each candidate, assuming that each table being joined didn't
>> individually have the same issue. I think that that's probably
>> considered the correct behavior by most.
>
> It seems pretty silly to me actually. Was this designed by a committee?
> I agree with the general principle that showing a large number of
> candidates (a la bash) is a bad idea, but failing to show two of them ...

I guess it was designed by a committee. But we don't fail to show both
because they're equally distant. Rather, it's because they're equally
distant and from the same RTE. This is a contrived example, but
typically showing equally distant columns is useful when they're in a
foreign-key relationship - I was worried about the common case where a
column name is misspelled that would otherwise be ambiguous, which is
why that shows a HINT while the single RTE case doesn't. I think that
in most realistic cases it wouldn't be all that useful to show two
columns from the same table when they're equally distant. It's easy to
imagine that reflecting that no match is good in absolute terms, and
we're somewhat conservative about showing any match. While I think
this general behavior is defensible, I must admit that it did suit me
to write it that way because to do otherwise would have necessitated
more invasive code in the existing general purpose scanRTEForColumn()
function.

--
Peter Geoghegan