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
>
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
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
>
> 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:
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
> -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
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
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
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
>
> 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
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
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
> 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
> 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
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,
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
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
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
> [ 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
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
> 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
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
22 matches
Mail list logo
