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

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Jim Nasby <jim(at)nasby(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date: 2014-11-12 21:13:53
Message-ID: CAM3SWZTyGk5s9LYJjABpBbjsUUXdoWc6Rq4H8xU01Z9Veegd8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 12, 2014 at 12:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I agree with your proposed approach to moving Levenshtein into core.
> However, I think this should be separated into two patches, one of
> them moving the Levenshtein functionality into core, and the other
> adding the new treatment for missing column errors. If you can do
> that relatively soon, I'll make an effort to get the refactoring patch
> committed in the near future. Once that's done, we can focus in on
> the interesting part of the patch, which is the actual machinery for
> suggesting alternatives.

Okay, thanks. I think I can do that fairly soon.

> On that topic, I think there's unanimous consensus against the design
> where equally-distant matches are treated differently based on whether
> they are in the same RTE or different RTEs. I think you need to
> change that if you want to get anywhere with this.

Alright. It wasn't as if I felt very strongly about it either way.

> On a related note,
> the use of the additional parameter AttrNumber closest[2] to
> searchRangeTableForCol() and of the additional parameters AttrNumber
> *matchedatt and int *distance to scanRTEForColumn() is less than
> self-documenting. I suggest creating a structure called something
> like FuzzyAttrMatchState and passing a pointer to it down to both
> functions.

Sure.
--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-12 21:36:30 Re: Add CREATE support to event triggers
Previous Message Robert Haas 2014-11-12 21:11:58 Re: REINDEX CONCURRENTLY 2.0