On Tue, Apr 1, 2014 at 7:25 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
