Re: Doing better at HINTing an appropriate column within errorMissingColumn() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date
Msg-id CA+Tgmoayvd0sHd8WnLm1NAR7+BwbRE5TB-L59AJtGBZYGX4rvQ@mail.gmail.com
Whole thread Raw
In response to Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Fri, Dec 5, 2014 at 3:45 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Dec 5, 2014 at 12:33 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Well, if an alias is used, and you refer to an attribute using a
>>> non-alias name (i.e. the original table name), then you'll already get
>>> an error suggesting that the alias be used instead -- of course,
>>> that's nothing new. It doesn't matter to the existing hinting
>>> mechanism if the attribute name is otherwise wrong. Once you fix the
>>> code to use the alias suggested, you'll then get this new
>>> Levenshtein-based hint.
>>
>> In that case, I think I favor giving no hint at all when the RTE name
>> is specified but doesn't match exactly.
>
> I don't follow. The existing mechanism only concerns what to do when
> the original table name was used when an alias should have been used
> instead. What does that have to do with this patch?

Just that that's the case in which it seems useful to give a hint.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Ronan Dunklau
Date:
Subject: Dumping database creation options and ACLs
Next
From: Robert Haas
Date:
Subject: Re: alter user set local_preload_libraries.