On Wed, Jul 9, 2014 at 2:19 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
>> That's harder than it sounds. You need even more translatable strings
>> for variant ereports().
> Maybe it is possible to rephrase the message so that the translatable
> part doesn't need to concern with how many suggestions there are. For
> instance something like "perhaps you meant a name from the following
> list: foo, bar, baz". Couple with the errmsg_plural stuff, you then
> don't need to worry too much about providing different strings for 1, 2,
> N suggestions.
That's not really the problem. I already have a lot of things to test
in each of the two ereport() calls. More importantly, showing the
closet, say, 3 matches under an arbitrary distance does not weigh
concerns about that indicating that they're all bad. It's not like
bash tab completion - if there is one best match, that's probably
because that's what the user meant. Whereas if there are two or more
within a single RTE, that's probably because both are unhelpful. They
both happened to require the same number of substitutions to get to,
while not being quite bad enough matches to be excluded by the final
check against a normalized distance threshold (the final check that
prevents ludicrous suggestions).
The fact that there were multiple equally plausible candidates (that
are not identically named and just from different RTEs) tells us
plenty, unlike with tab completion. It's not hard for one column to be
a better match than another, and so it doesn't seem unreasonable to
insist upon that within a single RTE where they cannot be identical,
since a conservative approach seems to be what is generally favored.
In any case I'm just trying to weigh everyone's concerns here. I hope
it's actually possible to compromise, but right now I don't know what
I can do to make useful progress.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: