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 CAM3SWZTpTrpjTEyJT2mMK1MhaA10ZufffpN+HtkfSe0Kkg+maQ@mail.gmail.com
Whole thread Raw
In response to Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On Tue, Apr 1, 2014 at 7:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> There's a risk of adding not
> only CPU cycles but also clutter.  If we do things that encourage
> people to crank the log verbosity down, I think that's going to be bad
> more often than it's good.

While I share your concern here, I think that this is something that
is only likely to be seen in an interactive psql session, where it is
seen quite frequently. I am reasonably confident that it's highly
unusual to see ERRCODE_UNDEFINED_COLUMN in other settings. Not having
to do a mental context switch when writing an ad-hoc query has
considerable value. Even C compilers like Clang have this kind of
feedback.   This is a patch that was written out of personal
frustration with the experience of interacting with many different
databases. Things like the Python REPL don't do so much of this kind
of thing, but presumably that's because of Python's dynamic typing.
This is a HINT that can be given with fairly high confidence that
it'll be helpful - there just won't be that many things that the user
could have meant to choose from. I think it's even useful when the
suggested column is distant from the original suggestion (i.e.
errorMissingColumn() offers only what is clearly a "wild guess"),
because then the user knows that he or she has got it quite wrong.
Frequently, this will be because the wrong synonym for what should
have been written was used.

> It strains credulity to think that this
> patch alone would have that effect, but there might be quite a few
> similar improvements that are possible.  So I think it would be good
> to consider how far we want to go in this direction and where we think
> we might want to stop.  That's not to say, let's not ever do this,
> just, let's think carefully about where we want to end up.

Fair enough.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: get_fn_expr_variadic considered harmful
Next
From: Pavel Stehule
Date:
Subject: Re: four minor proposals for 9.5