On Sun, Dec 14, 2014 at 8:24 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Dec 9, 2014 at 2:52 AM, Peter Geoghegan <p...@heroku.com> wrote: >> On Mon, Dec 8, 2014 at 9:43 AM, Peter Geoghegan <p...@heroku.com> wrote: >>> I think it's very possible that the wrong alias may be provided by the >>> user, and that we should consider that when providing a hint. >> >> Note that the existing mechanism (the mechanism that I'm trying to >> improve) only ever shows this error message: >> >> "There is a column named \"%s\" in table \"%s\", but it cannot be >> referenced from this part of the query." >> >> I think it's pretty clear that this general class of user error is common. > Moving this patch to CF 2014-12 as work is still going on, note that > it is currently marked with Robert as reviewer and that its current > status is "Needs review".
The status here is more like "waiting around to see if anyone else has an opinion". The issue is what should happen when you enter qualified name like alvaro.herrera and there is no column named anything like herrara in the RTE named alvaro, but there is some OTHER RTE that contains a column with a name that is only a small Levenshtein distance away from herrera, like roberto.correra. The questions are: 1. Should we EVER give a you-might-have-meant hint in a case like this? 2. If so, does it matter whether the RTE name is just a bit different from the actual RTE or whether it's completely different? In other words, might we skip the hint in the above case but give one for alvara.correra? My current feeling is that we should answer #1 "no", but Peter prefers to answer it "yes". My further feeling is that if we do decide to say "yes" to #1, then I would answer #2 as "yes" also, but Peter would answer it "no", assigning a fixed penalty for a mismatched RTE rather than one that varies by the Levenshtein distance between the RTEs. If no one else expresses an opinion, I'm going to insist on doing it my way, but I'm happy to have other people weigh in. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
