From: Ian Barwick <ian@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Peter Geoghegan <pg@heroku.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Greg Stark <stark@mit.edu>
Cc: Jim Nasby <jim@nasby.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Albe Laurenz <laurenz.albe@wien.gv.at>
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Date: Tue, 17 Jun 2014 11:09:53 +0900
Message-ID: <539FA371.4070902@2ndquadrant.com> (raw)
In-Reply-To: <27925.1402966428@sss.pgh.pa.us>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ian@2ndquadrant.com, tgl@sss.pgh.pa.us, michael.paquier@gmail.com, pg@heroku.com, josh@agliodbs.com, andres@2ndquadrant.com, stark@mit.edu, jim@nasby.net, robertmhaas@gmail.com, laurenz.albe@wien.gv.at
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
In-Reply-To: <539FA371.4070902@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox