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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Дата
Msg-id CAM3SWZTpTrpjTEyJT2mMK1MhaA10ZufffpN+HtkfSe0Kkg+maQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Doing better at HINTing an appropriate column within errorMissingColumn()  (Jim Nasby <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: get_fn_expr_variadic considered harmful
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: four minor proposals for 9.5