The following function:
create function text_to_words(text)
returns setof text as $_$
my %stopwords = ( 'i' => 'i','me' => 'me','my' => 'my','myself' =>
'myself','we' => 'we','our' => 'our','ours' => 'ours','ourselves' =>
'ourselves','you' => 'you','your' => 'your','yours' => 'yours','yourse
> Works fine for me. What encoding/locale are you using?
unicode / c
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
PostgreSQL 8.0b4 as released.
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',1);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',2);
select split_part('a b c d e f g h i j k l m n o p q r s t u v w x y
z',' ',3);
select split_part('a b c d e
> [ shrug... ] Works fine for me in unicode, too.
never mind me,. I broke it.
seems my assumption that UCS2 == UTF16 was way off
... john
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
On occasion, it seems the psql history file gets truncated.
Unable to replicate, it just seems to happen every now and then.
... John
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregiste
It seems rules don't work as expected.
I could be wrong,... In which case, what am I doing wrong?
Clearly, the first insert below should not update the table as well.
... John
CREATE TABLE test (a text, b int4[]);
CREATE RULE test_rule AS
ON INSERT TO test
WHERE exists(SELECT 1 FROM test
essage-
> From: Richard Huxton [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 12, 2005 10:22 PM
> To: John Hansen
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] RULES doesn't work as expected
>
> Removed cc to pgsql-patches since that's not the li
The following seems to me a bug in either initdb or create operator:
CREATE FUNCTION my_func (inet, inet) as '$libdir/my_func.so' LANGUAGE 'C'
IMMUTABLE STRICT;
CREATE OPERATOR <<< (
PROCEDURE = my_func,
LEFTARG = cidr,
RIGHTARG = cidr,
RESTRICT = contsel,
> My opinion is that this is a very bogus shortcut in the
> network datatype code. There are no cases outside the
> inet/cidr group where an operator doesn't exactly match its
> underlying function. (The whole business of inet and cidr
> being almost but not quite the same type is maldesigned
> It seems what's happening here is that dspam is submitting a
> query with many thousands of elements in the IN clause. In
> the parser, we transform "foo IN (a, b, c)" into "foo = a OR
> foo = b OR foo = c", and then recurse for each element of the
> OR expression and eventually run out of st
Try the replacement upper/lower functions that I wrote:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00102.php
Kind regards,
John Hansen
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Staffan Sandberg
> Sent: Tuesday, Ma
5-02/msg00102.php
Kind regards,
John Hansen
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Staffan Sandberg
> Sent: Tuesday, March 22, 2005 8:28 PM
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] BUG #1557: UPPER() and LOWER() do
>
> It is really hard to currently alter table schema.
>
> Particularly the order of the table schema.
>
> to move a column position is very hard. worse if your table as
references (and which proper
> tables don't ?)
Doesn't that in itself promote bad progra
Would someone be kind enough to advise this person to update his
antispam software, so that it doesn't include all of australia as
spammers?
Kind Regards,
John Hansen
_
From: System Administrator
Sent: Saturday, M
Maybe you restored to template1 by mistake?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Toltzman
> Sent: Monday, May 23, 2005 4:38 AM
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] drop + create database restores previous
> tables a
I've seen this before, and that was due to unaligned memory access,
which is not supported on some platforms.
I thought we didn't do unaligned memory access??
... John
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Haluk GUNCER
> Sent: Wednesday
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Wolff III
> Sent: Friday, June 03, 2005 11:58 PM
> To: Mauro Delfino
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #1698: Different behavior in UNIQUE
> and DISTINCT
>
> On Thu, J
FYI, Works just fine on gentoo with the UTF8 and ICU patches.
... John
> This bug happens in SUSE 9.3 on both Pentium 4 and AMD64,
> whether the binaries are from postgresql-8.0.1 RPMs on the
> SUSE 9.3 DVD or are built from 8.0.3 source code. However
> this bug does NOT happen with a Debian
>
> UTF8 encoding works with the C locale assuming you don't care
> about ordering of the character set, e.g. Japanese.
>
Has anyone with the ability to compile postgresql on windows tested the
ICU patch?
... John
---(end of broadcast)---
TIP 5:
Magnus Hagander Wrote:
> > > PostgreSQL 8.0 does not support UTF8 on Win32. You will need to
> > > convert the file before you load it into the database -
> look at for
> > > example the GNU iconv program to do this.
> >
> > PostgreSQL does not support UTF8 locales on Windows, but
> the charac
Since column is boolean, you need a boolean result:
insert into table (column) values (nullif(true,true));
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt A.
> Sent: Monday, August 22, 2005 3:22 AM
> To: pgsql-bugs@postgresql.org; pgsql-patch
Paul,
To fix your dump so it will import, run:
iconv -c -f UTF8 -t UTF8 -o fixed.sql dump.sql
Kind Regards,
John Hansen
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Lindner
> Sent: Sunday, October 23, 2005 1:34 AM
>
22 matches
Mail list logo
