Hitoshi,
there is no problem to write n-gram dictionary for tsearch2 ! The problem
is in how to define word boundary.
Oleg
On Sat, 26 May 2007, Hitoshi Harada wrote:
FYI, Tatsuo uses tsearch2 for indexing japanese documents. But I agree,
n-gram index would be more universal for asian
I just rearranged the code in mbutils.c a little bit to make it more
robust if conversion of an over-length string is attempted, and noted
this comment:
/*
* When converting strings between different encodings, we assume that space
* for converted result is 4-to-1 growth in the worst case. The
If both libedit and libreadline are available, we currently default to
linking against libreadline, unless the --with-libedit-preferred
configure option is used. Why do we default to preferring GNU readline
over libedit?
libedit is clearly preferable for license reasons. You could make the
Neil Conway [EMAIL PROTECTED] writes:
If both libedit and libreadline are available, we currently default to
linking against libreadline, unless the --with-libedit-preferred
configure option is used. Why do we default to preferring GNU readline
over libedit?
readline has much more
On Fri, 2007-04-13 at 16:09 +0100, Simon Riggs wrote:
I'll make the agreed changes by next Wed/Thurs.
I am actively working on this now, after some delays because of other
calls on my time. The suggested changes have needed more rework than I
estimated, touching most lines of the patch, but I
Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php
---
Richard Huxton wrote:
Florian G. Pflug
bruce wrote:
* Re: [HACKERS] Modifying TOAST thresholds /Tom Lane/
At this point it seems nothing will be done about this issue for 8.3.
I'm not sure anyone has an idea how to test it. TPCC isn't really useful
because it has a fixed size (500 byte) string buffer. Perhaps if we
I just rearranged the code in mbutils.c a little bit to make it more
robust if conversion of an over-length string is attempted, and noted
this comment:
/*
* When converting strings between different encodings, we assume that space
* for converted result is 4-to-1 growth in the worst
[EMAIL PROTECTED] (Bruce Momjian) writes:
The results are here:
http://momjian.us/expire/TOAST/
I'll take a look and see if there's anything further it makes sense
for me to try testing. Thanks for following up so quickly; what with
the cold I have had, I haven't yet gotten back to the
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm afraid we have to mke it larger, rather than smaller for 8.3. For
example 0x82f5 in SHIFT_JIS_2004 (new in 8.3) becomes *pair* of 3
bytes UTF_8 (0x00e3818b and 0x00e3829a). See
util/mb/Unicode/shift_jis_2004_to_utf8_combined.map for more details.
So
* Tom Lane ([EMAIL PROTECTED]) wrote:
I would like to fix this for 8.3. I don't have a patch yet but want
to get buy-in on a design before feature freeze. I propose the
following, fully-backward-compatible design:
[...]
Comments?
In talking w/ Jeff Davis on IRC today, another thought
Stephen Frost [EMAIL PROTECTED] writes:
It would be useful to have a function which could be passed a relative
(to the caller's search path) object name and would return the fully
qualified name of that object. In this way, functions could be written
which take relative arguments from the
Can we add a column to pg_conversion which represents the growth
rate? This would reduce the rate for most encodings much smaller than
6.
We need to do something, but the pg_conversion catalog seems a bad place
to put the info --- don't we have places that need to be able to do
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
It would be useful to have a function which could be passed a relative
(to the caller's search path) object name and would return the fully
qualified name of that object. In this way, functions could be written
Stephen Frost [EMAIL PROTECTED] writes:
The 'special' bit here is that pg_getfullpath() would work relative to
the caller's search_path even inside of a function which has its 'PATH'
set.
Eeek. *Which* caller's search_path? The string you're handed might've
come from multiple levels up.
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
The 'special' bit here is that pg_getfullpath() would work relative to
the caller's search_path even inside of a function which has its 'PATH'
set.
Eeek. *Which* caller's search_path? The string you're handed
On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm afraid we have to mke it larger, rather than smaller for 8.3. For
example 0x82f5 in SHIFT_JIS_2004 (new in 8.3) becomes *pair* of 3
bytes UTF_8 (0x00e3818b and 0x00e3829a). See
On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm afraid we have to mke it larger, rather than smaller for 8.3. For
example 0x82f5 in SHIFT_JIS_2004 (new in 8.3) becomes *pair* of 3
bytes UTF_8 (0x00e3818b and 0x00e3829a). See
18 matches
Mail list logo
