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

From Peter Geoghegan
Subject Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date
Msg-id CAM3SWZSaA1298Os+9q_jZyn-p37AFv9bjU=3paNQr-U4yCTwwg@mail.gmail.com
Whole thread Raw
In response to Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 20, 2014 at 12:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I do not have a problem with deciding that that is not a "regression";
> in fact, not giving that hint seems like a good conservative behavior
> here.  By your logic, we should also be prepared to suggest
> "supercalifragilisticexpialidocious" when the user enters "ocious".

That's clearly not true. I just want to be a bit more forgiving of
omissions. That clearly isn't my logic, since that isn't a suggestion
that the implementation will give, or would be anywhere close to
giving - my weighing of deletions is only twice that of substitutions
or insertions, not ten times. git does not use Levenshtein default
costings either.

> It's simply a bridge too far for what is supposed to be a hint for
> minor typos.

Minor typos and minor omissions. My example was on the edge of what
would be tolerable under my proposed cost model.

> You sound like you want to turn it into something that
> will look up column names for people who are too lazy to even try to
> type the right thing.  While I can see the value of such a tool within
> certain contexts, firing completed queries at a live SQL engine
> is not one of them.

It's just a hint; a convenience. Users who imagine that it takes away
the need for putting any thought into their SQL queries have bigger
problems.

Anyway, that's all that needs to be said on that, since I've already
given up on a non-default costing. Also, we have default costing, and
we always apply a 50% standard (I see no point in doing otherwise with
default costings).

Robert: Where does that leave us? What about suggestions across RTEs?
Alias costing, etc?
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: pg_multixact not getting truncated
Next
From: Robert Haas
Date:
Subject: Re: group locking: incomplete patch, just for discussion