Message-ID: <539FA371.4070902@2ndquadrant.com>
Date: Tue, 17 Jun 2014 11:09:53 +0900
From: Ian Barwick <ian@2ndquadrant.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael.paquier@gmail.com>
CC: Peter Geoghegan <pg@heroku.com>, Josh Berkus <josh@agliodbs.com>,
 Andres Freund <andres@2ndquadrant.com>,
 Greg Stark <stark@mit.edu>, Jim Nasby <jim@nasby.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>,
 Albe Laurenz <laurenz.albe@wien.gv.at>
Subject: Re: Doing better at HINTing an appropriate column within
 errorMissingColumn()
References: 
 <CAM3SWZS9-Xr2Ud_j9yrKDctT6xxy16h1EugtSWmLU6Or4CtGAA@mail.gmail.com>
 <A737B7A37273E048B164557ADEF4A58B17CE8DEA@ntex2010i.host.magwien.gv.at>
 <CA+TgmoY+DMJgE+B4M9qP2Uauwu-iJxs0ynCqSEtQZ_Y0TbMYxw@mail.gmail.com>
 <CAM3SWZTpTrpjTEyJT2mMK1MhaA10ZufffpN+HtkfSe0Kkg+maQ@mail.gmail.com>
 <533B31C9.1080403@nasby.net>
 <CAM-w4HOTRoPJHT3J=nEvzQwWUTh5QzW77MGB1umQRL28b2D64g@mail.gmail.com>
 <20140402201602.GV3750@awork2.anarazel.de>
 <WM!fa5058a0cf78e105e4943455e049a6e231537de5b73a550f4e6fbb7aa0182ba1833f03f49d84ffc0ab7bb7c5a90e7f19!@asav-1.01.com>
 <539F7816.1070809@agliodbs.com>
 <CAM3SWZQj1QOFNugKcev4z9ff9CxBfy1qxyxnHitdk+YA-ca2EA@mail.gmail.com>
 <539F8C26.3040500@2ndquadrant.com>
 <CAB7nPqS-YtRHKi0gHCkB2L=G9aiVsZg478kRxO_J280dzm66Xw@mail.gmail.com>
 <27925.1402966428@sss.pgh.pa.us>
In-Reply-To: <27925.1402966428@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 14/06/17 9:53, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Tue, Jun 17, 2014 at 9:30 AM, Ian Barwick <ian@2ndquadrant.com> wrote:
>>> From what I've seen in the wild in Japan, Roman/ASCII characters are
>>> widely used for object/attribute names, as generally it's much less
>>> hassle than switching between input methods, dealing with different
>>> encodings etc. The only place where I've seen Japanese characters widely
>>> used is in tutorials, examples etc. However that's only my personal
>>> observation for one particular non-Roman language.
> 
>> And I agree to this remark, that's a PITA to manage database object
>> names with Japanese characters directly. I have ever seen some
>> applications using such ways to define objects though in the past, not
>> *that* many I concur..
> 
> What exactly is the rationale for thinking that Levenshtein distance is
> useless in non-Roman alphabets?  AFAIK it just counts insertions and
> deletions of characters, which seems like a concept rather independent
> of what those characters are.

With Japanese (which doesn't have an alphabet, but two syllabaries and
a bunch of logographic characters), Levenshtein distance is pretty useless
for examining similarities with words which can be written in either
syllabary (Michael's "ramen" example earlier in the thread); and when
catching "typos" caused by erroneous conversion from phonetic input to
characters - e.g. intending to input "成長" (seichou, growth) but
accidentally selecting "清聴" (seichou, courteous attention).

Howver in this particular use case, as long as it doesn't produce false
positives (I haven't looked at the patch) I don't think it would cause
any problems (of the kind which would require actively excluding certain
languages/character sets), it just wouldn't be quite as useful.


Regards

Ian Barwick

-- 
 Ian Barwick                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers