Hi,
ltree and pg_trgm with UTF8 support are available from CVS HEAD, see
See http://archives.postgresql.org/pgsql-committers/2008-06/msg00356.php
http://archives.postgresql.org/pgsql-committers/2008-11/msg00139.php
Oleg
On Fri, 16 Jan 2009, pepone.onrez wrote:
On Sat, Apr 19, 2008 at 6:10 PM,
On Sat, Apr 19, 2008 at 6:10 PM, Oleg Bartunov wrote:
> On Sat, 19 Apr 2008, Tom Lane wrote:
>
>> Craig Ringer writes:
>>>
>>> Tom Lane wrote:
I don't really see the problem. I assume from your reference to pg_trgm
that you're using trigram similarity as the prefilter for potentia
Tom Lane wrote:
True. It's not so much the speed as the fragility when faced with small
changes to formatting. In addition to whitespace, some clients mangle
punctuation with features like automatic "curly"-quoting.
Yeah. I was wondering whether encoding differences wouldn't be a huge
proble
On Sat, 19 Apr 2008, Tom Lane wrote:
Craig Ringer <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I don't really see the problem. I assume from your reference to pg_trgm
that you're using trigram similarity as the prefilter for potential
matches
It turns out that's no good anyway, as it appear
Craig Ringer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't really see the problem. I assume from your reference to pg_trgm
>> that you're using trigram similarity as the prefilter for potential
>> matches
> It turns out that's no good anyway, as it appears to ignore characters
> outsi
Tom Lane wrote:
I don't really see the problem. I assume from your reference to pg_trgm
that you're using trigram similarity as the prefilter for potential
matches
It turns out that's no good anyway, as it appears to ignore characters
outside the ASCII range. Rather less than useful for sear
Craig Ringer <[EMAIL PROTECTED]> writes:
> It's also useful for format-string based messages, but more thought is
> needed on how best to handle them. A LIKE query using the format-string
> message as the pattern (after converting the pattern syntax to SQL
> style) would be (a) slow and (b) very
Hi all
I've chucked together a quick and very ugly script to read the .po files
from the backend and produce a simple database to map translations back
to the original strings and their source locations. It's a very dirty
.po reader that doesn't try to parse the format properly, but it does
t
