On Tue, Jul 8, 2014 at 1:42 PM, Alvaro Herrera <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
