On Sun, Dec 14, 2014 at 8:24 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Dec 9, 2014 at 2:52 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> On Mon, Dec 8, 2014 at 9:43 AM, Peter Geoghegan <pg@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
