On Wed, 2017-08-09 at 14:21 +0200, basti wrote:
> Hello,
> i have a webapp convert from ascii to uft8.
>
> Now I get in postgres
>
> ERROR: invalid byte sequence for encoding "UTF8": 0xfc
>
> Now I try to log all queries with log_statement = 'all'.
> All queries are longed expected this one.
John et al,
On Mon, Jul 31, 2017 at 12:13 AM, Igor Korot wrote:
> John,
>
> On Sun, Jul 30, 2017 at 5:32 PM, Igor Korot wrote:
>> Hi, John,
>>
>> On Sun, Jul 30, 2017 at 4:53 PM, John R Pierce wrote:
>>> On 7/30/2017 1:43 PM, Igor Korot wrote:
>>>
>>> what encodings are default on your system ?
John,
On Sun, Jul 30, 2017 at 5:32 PM, Igor Korot wrote:
> Hi, John,
>
> On Sun, Jul 30, 2017 at 4:53 PM, John R Pierce wrote:
>> On 7/30/2017 1:43 PM, Igor Korot wrote:
>>
>> what encodings are default on your system ?`\l+` in psql should show the
>> encodings.
>>
>> Is this "backslash + pi
Hi, John,
On Sun, Jul 30, 2017 at 4:53 PM, John R Pierce wrote:
> On 7/30/2017 1:43 PM, Igor Korot wrote:
>
> what encodings are default on your system ?`\l+` in psql should show the
> encodings.
>
> Is this "backslash + pipe + plus-sign"?
>
> Trying it gives: "Invalid command".
>
>
> \ + low
On 7/30/2017 1:43 PM, Igor Korot wrote:
what encodings are default on your system ?`\l+` in psql should show the
encodings.
Is this "backslash + pipe + plus-sign"?
Trying it gives: "Invalid command".
\ + lower case L + plus sign, thats the psql metacommand to list all
databases with ext
Hi, John,
On Sun, Jul 30, 2017 at 4:34 PM, John R Pierce wrote:
> On 7/30/2017 1:19 PM, Igor Korot wrote:
>>
>> I am using a database for my project that I created inside SQLite3.
>> This database contains a table called "abc" (it is "abc" +
>> symbol with the code 225 -
>> greek letter "beta or
On 7/30/2017 1:19 PM, Igor Korot wrote:
I am using a database for my project that I created inside SQLite3.
This database contains a table called "abc" (it is "abc" +
symbol with the code 225 -
greek letter "beta or a German symbol for "ss").
in what encoding? in ISO 8859-1, -15, beta aka sha
On Sat, Nov 19, 2011 at 09:32:12AM -0800, pawel_kukawski wrote:
> Is there any way I can store NULL character (\u) in string ?
>
> Or there is only one option that I have change every text field to bytea.
correct question is: why do you want to store \u in text field?
Best regards,
depe
BRUSSER Michael wrote:
>>> Is there a way to find the records with the text field containing
Unicode bytes "0xedbebf"?
>>> Unfortunately this is a very old version 7.3.10
>>
>> This should work on 7.3 (according to the documentation):
>> SELECT id FROM nlsdata WHERE position('\360\235\204\236'::byt
-Original Message-
From: Albe Laurenz [mailto:laurenz.a...@wien.gv.at]
Sent: Thursday, June 16, 2011 5:16 AM
To: BRUSSER Michael; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Invalid byte sequence for encoding "UTF8": 0xedbebf
BRUSSER Michael wrote:
> Is there a wa
BRUSSER Michael wrote:
> Is there a way to find the records with the text field containing
Unicode bytes "0xedbebf"?
>
> Unfortunately this is a very old version 7.3.10
This should work on 7.3 (according to the documentation):
SELECT id FROM nlsdata WHERE position('\360\235\204\236'::bytea IN
val
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Alan Hodgson
Sent: Wednesday, June 15, 2011 5:37 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Invalid byte sequence for encoding "UTF8": 0xedbebf
On June 15, 2011 01:18:27 PM BRUSSER Michael wrote:
> Unless there's no other options I don't want to use sed or break file into
> pieces, if possible,
iconv loads everything into RAM. You can use "split", convert the pieces, and
then recombine, I did that when converting a large database to utf-
That specific character sequence is a result of Unicode implementations
prior to 6.0 mixing with later implementations. See here:
http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29#Replacement_character
You could replace that sequence with the correct 0xFFFD sequence with `sed`
for exampl
2011/5/12 Craig Ringer :
> On 05/11/2011 03:16 PM, AI Rumman wrote:
>>
>> I am trying to migrate a database from Postgresql 8.2 to Postgresql 8.3
>> and getting the following error:
>>
>> pg_restore: [archiver (db)] Error from TOC entry 2764; 0 29708702 TABLE
>> DATA originaldata postgres
>> pg_res
On 05/11/2011 03:16 PM, AI Rumman wrote:
I am trying to migrate a database from Postgresql 8.2 to Postgresql 8.3
and getting the following error:
pg_restore: [archiver (db)] Error from TOC entry 2764; 0 29708702 TABLE
DATA originaldata postgres
pg_restore: [archiver (db)] COPY failed: ERROR: in
On 4/03/2011 10:18 PM, Maximilian Tyrtania wrote:
Am 04.03.2011 um 11:01 schrieb Craig Ringer:
On 04/03/11 00:02, Maximilian Tyrtania wrote:
After upgrading to pg 9.0.3 (from 8.4.2) on my Mac OS 10.6.2 machine i find
this in my log file (a lot):
STATEMENT: SELECT
pg_file_read('pg_log/postg
Am 04.03.2011 um 11:01 schrieb Craig Ringer:
> On 04/03/11 00:02, Maximilian Tyrtania wrote:
>> After upgrading to pg 9.0.3 (from 8.4.2) on my Mac OS 10.6.2 machine i find
>> this in my log file (a lot):
>>
>> STATEMENT: SELECT
>> pg_file_read('pg_log/postgresql-2011-03-03_00.log', 25,
On 04/03/11 00:02, Maximilian Tyrtania wrote:
> After upgrading to pg 9.0.3 (from 8.4.2) on my Mac OS 10.6.2 machine i find
> this in my log file (a lot):
>
> STATEMENT: SELECT
> pg_file_read('pg_log/postgresql-2011-03-03_00.log', 25, $
> ERROR: invalid byte
> sequence for encoding "U
Was the original DB in UTF8 encoding? You need to make sure the new
DB is created with the same encoding as the original, or do the
necessary translations using something like iconv.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http:
Daniel Schuchardt wrote:
> but look here:
>
> X=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf=
> '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0
> Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *
> \r\n\\par }\r\n\0' WHERE ak_nr='TEST';
> WARNING: nonstandard use of \\ in a strin
Yes, you'r correct with the \0 at the end. The problem is that the
rtf-object returns wrong terminated string. i can fix the problem with a
trim.
but look here:
X=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf=
'{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0
Arial;}}\r\n\\viewkind4
> So its not possible thats our parser.
And
> Second:string:Not really: thats the orignal string, and its a string:
Look again. Where is the null character in the original string? Why does
your encoded string end with "\0"? In what character set is null a legal
character?
Your encoder is incorr
On Mon, 2009-09-14 at 00:36 +0200, Daniel Schuchardt wrote:
> I know you are true with definition's and standards, however, that code
> works for about 6 years ;o)
>
> Well, we will change our parser behavoir. We will check out that
> standard_conforming_strings parameter too but i see a lot of
Hi Thomas,
thanks a lot we will check out that parameter. But if i understand it in
the correct way that parameter will turn off all escape quoting.
I have to check out,
thanks a lot.
Thomas Kellerer schrieb:
Daniel Schuchardt wrote on 13.09.2009 18:51:
UPDATE belzeil_frei SET bz_zubez= '*
I know you are true with definition's and standards, however, that code
works for about 6 years ;o)
Well, we will change our parser behavoir. We will check out that
standard_conforming_strings parameter too but i see a lot of problems
with our backup and restore system (plain text pg_dump's) a
On sön, 2009-09-13 at 22:21 +0200, Daniel Schuchardt wrote:
> First:In Postgres81 everything is working fine.
In general, older versions of PostgreSQL treated encoding issues much
mroe loosely, which subsequently lead to user errors, bugs, and
confusion. Later versions are more strict. Therefore
Daniel Schuchardt wrote on 13.09.2009 18:51:
UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf=
'{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0
Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0'
WHERE dbrid=295116
Result : ERROR: invalid byte sequence for encoding
First:In Postgres81 everything is working fine.
Second:string:Not really: thats the orignal string, and its a string:
(http://de.wikipedia.org/wiki/Rich_Text_Format)
(http://en.wikipedia.org/wiki/Rich_Text_Format)
{\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Arial;}}
\viewkind4\uc1\pard\lang
Hy Scott,
as wrote in my awnser to peter everything is working fine in Postgres81.
So its not possible thats our parser.
Please look in my awnser for peter.
Scott Ribe schrieb:
In that example i try to insert a "*" with rtf-encoding.
It's not the "*" causing the error, it's the "\0"--whi
> In that example i try to insert a "*" with rtf-encoding.
It's not the "*" causing the error, it's the "\0"--which I'm pretty sure is
not a valid character for an RTF file either. Do you have an encoder which
is just blindly reading through the null terminator of a C string and
including it in th
On sön, 2009-09-13 at 18:51 +0200, Daniel Schuchardt wrote:
> UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf=
> '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0
> Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0'
> WHERE dbrid=295116
>
> Result : ERROR: invalid b
"Grand, Mark D." writes:
> It turns out that my problem was that the editor I was using (emacs)
> does not properly support utf8 encoding.
Emacs does support utf8 properly.
http://www.emacswiki.org/emacs/ChangingEncodings
It could be I'm biased because I use emacs from CVS, which is going to
] invalid byte sequence for encoding "UTF8": 0xab
Mark D. Grand wrote:
> I am having a vexing problem with a script I am writing to
> populate reference tables in a new database.
>
> I am running postgreSQL 8.3 with psql 8.3.7.
>
> Psql reads this SQL st
Mark D. Grand wrote:
> I am having a vexing problem with a script I am writing to
> populate reference tables in a new database.
>
> I am running postgreSQL 8.3 with psql 8.3.7.
>
> Psql reads this SQL statement:
>
> INSERT INTO META_AUTH.DOMAIN_META_ASSERTION (TITLE, DESCRIPTION,
> META_
On Fri, Jun 5, 2009 at 9:57 AM, Tom Lane wrote:
> The ASCII code for '<' is 0x3c, not 0xab. I am not sure what you are
> actually typing; although it's suggestive that the LATIN1 code 0xab
> corresponds to a symbol that looks approximately like '<<'. The most
> likely bet is that you are typing t
"Grand, Mark D." writes:
> ... I get this message:
> ERROR: invalid byte sequence for encoding "UTF8": 0xab
> HINT: This error can also happen if the byte sequence does not match the
> encoding expected by the server, which is controlled by "client_encoding".
> It is complaining about the '<'
On Fri, Nov 14, 2008 at 01:58:04PM +0100, Markus Wollny wrote:
> Hi!
>
> I am currently struggling with a couple oif tainted bytes in one of
> our PostgreSQL 8.2 databases which I plan to move to 8.3 soon - so I
> need to dump & restore.
At some point there was a plpgsql function posted that you
On Jul 24, 8:06 pm, [EMAIL PROTECTED] (AlannY) wrote:
> Hi there.
>
> Many times, I'm confronting with that strange problem: invalid byte
> sequence for encoding "UNICODE". So, I guess, Postgresql can't allow me
> to use some symbols which is not a part of UNICODE. But what is that
> symbals?
>
> I
AlannY <[EMAIL PROTECTED]> writes:
> Many times, I'm confronting with that strange problem: invalid byte
> sequence for encoding "UNICODE". So, I guess, Postgresql can't allow me
> to use some symbols which is not a part of UNICODE. But what is that
> symbals?
Doesn't it tell you? AFAICS every
Glyn Astill wrote:
> I've setup a postgres 8.2 server and have a database setup with UTF8
> encoding. I intend to read some of our legacy data into the table,
> this legacy data is in ASCII format, and as far as I know is 8 bit
> ASCII.
>
> We have a migration tool from mertechdata.com to convert
On Fri, Nov 30, 2007 at 09:44:36AM +, Glyn Astill wrote:
> I've setup a postgres 8.2 server and have a database setup with UTF8
> encoding. I intend to read some of our legacy data into the table,
> this legacy data is in ASCII format, and as far as I know is 8 bit
> ASCII.
Your problem is tha
[Generally it's not a good idea to start a new thread by responding to an
existing one, it confuses people and makes it more likely for your question to
be missed.]
"Glyn Astill" <[EMAIL PROTECTED]> writes:
> Hi People,
>
> I've setup a postgres 8.2 server and have a database setup with UTF8
>
On 11/30/07, Glyn Astill <[EMAIL PROTECTED]> wrote:
>
> Hi People,
>
> I've setup a postgres 8.2 server and have a database setup with UTF8
> encoding. I intend to read some of our legacy data into the table,
> this legacy data is in ASCII format, and as far as I know is 8 bit
> ASCII.
>
> We have
- Original Message -
From: "Albe Laurenz" <[EMAIL PROTECTED]>
To: "Ashish Karalkar *EXTERN*" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, September 03, 2007 4:54 PM
Subject: RE: [GENERAL] invalid byte sequence for encoding "UTF8": 0xff
Ashish K
Ashish Karalkar wrote:
>>> I have a data script which runs fine from PgAdmin SQL
>>> Editor,but when I run this from command prompt I get
>>> following error:
>>>
>>> test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
>>>
>>> psql:/usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql:1
- Original Message -
From: "Ashish Karalkar" <[EMAIL PROTECTED]>
To: "Albe Laurenz" <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2007 4:09 PM
Subject: Re: [GENERAL] invalid byte sequence for encoding "UTF8": 0xff
- Original M
Ashish Karalkar wrote:
> I have a data script which runs fine from PgAdmin SQL
> Editor,but when I run this from command prompt I get
> following error:
>
>
> test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
>
> psql:/usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql:1:
>
On Mon, Sep 03, 2007 at 01:36:58PM +0530, Ashish Karalkar wrote:
> Hello All,
>
> I have a data script which runs fine from PgAdmin SQL Editor,but when I run
> this from command prompt I get following error:
> test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
>
> psql:/usr/local/p
On Wed, Mar 21, 2007 at 09:54:41AM -0700, Alan Hodgson wrote:
> iconv needs to read the whole file into RAM. What you can do is use the
> UNIX split utility to split the dump file into smaller segments, use iconv
> on each segment, and then cat all the converted segments back together into
> a
On Wednesday 21 March 2007 04:17, "Fuzzygoth" <[EMAIL PROTECTED]>
wrote:
> I've searched the forums and found people with similar problems but
> not much
> on a way to remedy it. I did try using iconv which was suggested in a
> thread
> but it returned an error saying even the 22GB file was too la
On 1/16/07, Gary Benade <[EMAIL PROTECTED]> wrote:
I used shp2pgsql.exe to create an import sql for my gis database.
The resultant sql has data like this in it.INSERT INTO "gis"."sa_area"
("label","type","level",the_geom) VALUES
('MÔRELIG','0x2','2','01060001000');
The Ô is ascii char 21
On Tue, Jan 16, 2007 at 03:40:52PM +0200, Gary Benade wrote:
> I used shp2pgsql.exe to create an import sql for my gis database.
> The resultant sql has data like this in it.INSERT INTO "gis"."sa_area"
> ("label","type","level",the_geom) VALUES
> ('MÔRELIG','0x2','2','01060001000');
> The
Is this being done?
---
Karsten Hilbert wrote:
> On Thu, Aug 24, 2006 at 01:17:49PM -0400, Tom Lane wrote:
>
> > I guess the key point might be "what do we do if the client locale
> > is C?" Perhaps if it's C, we continue
On Fri, Aug 25, 2006 at 01:53:30PM +0200, Peter Eisentraut wrote:
> > In that case I would suggest to also emit a suitable warning
> > (with a postgresql.conf option to switch that off which
> > defaults to ON).
>
> libpq can neither read postgresql.conf nor does it have the liberty to write
> m
Am Donnerstag, 24. August 2006 23:22 schrieb Karsten Hilbert:
> In that case I would suggest to also emit a suitable warning
> (with a postgresql.conf option to switch that off which
> defaults to ON).
libpq can neither read postgresql.conf nor does it have the liberty to write
messages anywhere.
On Thu, Aug 24, 2006 at 01:17:49PM -0400, Tom Lane wrote:
> I guess the key point might be "what do we do if the client locale
> is C?" Perhaps if it's C, we continue to use the server encoding
> as we have in the past. This would be a reasonable fallback in
> other cases where we fail to deduce
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A possible solution therefore is to have psql or libpq drive the
>> client_encoding off the client's locale environment instead of
>> letting it default to equal the server_encoding.
> I have been proposing that for years, but just
Tom Lane wrote:
> A possible solution therefore is to have psql or libpq drive the
> client_encoding off the client's locale environment instead of
> letting it default to equal the server_encoding.
I have been proposing that for years, but just about now the Japanese
would speak up and protest .
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> It seems to me that setting the client encoding based on the
>> client-locale is the *only* sensible way of doing it.
> Yes please.
> FWIW I'm not sure if it really belongs in libpq, or it must be rather in
> psql (and
Martijn van Oosterhout wrote:
> For glibc systems we can get 100% reliable results. Even for other
> systems there's standard code out there for determining the charset.
> But this has been discussed before:
>
> http://archives.postgresql.org/pgsql-hackers/2003-05/msg00744.php
> http://archives.p
On Wed, Aug 23, 2006 at 06:52:00PM -0400, Tom Lane wrote:
> A possible solution therefore is to have psql or libpq drive the
> client_encoding off the client's locale environment instead of letting
> it default to equal the server_encoding. But I'm not sure what
> downsides that would have, and in
I wrote:
> We've known about this and related issues with gettext for some time,
> but a bulletproof solution isn't clear. For the moment all you can
> do is be real careful about making your locale settings match up.
I forgot to mention that it works fine if the server is told the client
encodin
Is this a TODO?
---
Tom Lane wrote:
> Andreas <[EMAIL PROTECTED]> writes:
> > I've got pg 8.1.4 from the binary Windows installer.
> > Windows 2000 / German
> > Now I entered "\d" into psql on the text-console and got this:
Andreas <[EMAIL PROTECTED]> writes:
> I've got pg 8.1.4 from the binary Windows installer.
> Windows 2000 / German
> Now I entered "\d" into psql on the text-console and got this:
>
> db_test=# \d
> ERROR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a
I can replicate this by using a
Bruce Momjian schrieb:
Andreas wrote:
I've got pg 8.1.4 from the binary Windows installer.
Windows 2000 / German
Now I entered "\d" into psql on the text-console and got this:
db_test=# \d
ERROR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a
What's up ?
db_test was created UT
Andreas wrote:
> Hi,
>
> I've got pg 8.1.4 from the binary Windows installer.
> Windows 2000 / German
> Now I entered "\d" into psql on the text-console and got this:
>
> db_test=# \d
> ERROR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a
>
> What's up ?
> db_test was created UTF8 e
Nis Jorgensen wrote:
> Oliver A. Rojo wrote:
>> how do you fix your original db?
>>
>
> Since I had only 3 occurrences of the error, I used
> hand-crafted update statements. The fact that the replacement
> for the invalid characters was constant and plain ascii made
> this very easy.
>
> If you
Markus Wollny wrote:
Nis Jorgensen wrote:
Oliver A. Rojo wrote:
how do you fix your original db?
Since I had only 3 occurrences of the error, I used
hand-crafted update statements. The fact that the replacement
for the invalid characters was constant and plain ascii made
this
Oliver A. Rojo wrote:
Nis Jorgensen wrote:
Oliver A. Rojo wrote:
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im
dumping data i got from my old db to my new db but eventually an
error occured
I fixed it by fixing the original db and dumping again. If this is not
desi
Nis Jorgensen wrote:
Oliver A. Rojo wrote:
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im
dumping data i got from my old db to my new db but eventually an
error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
I tried setting the client encoding t
Oliver A. Rojo wrote:
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
data i got from my old db to my new db but eventually an error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
I tried setting the client encoding to UNICODE but to no avail
Tom Lane wrote:
"Oliver A. Rojo" <[EMAIL PROTECTED]> writes:
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
data i got from my old db to my new db but eventually an error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
That's de
"Oliver A. Rojo" <[EMAIL PROTECTED]> writes:
> I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
> data i got from my old db to my new db but eventually an error occured
> ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
That's definitely not valid UNICODE (UTF-
74 matches
Mail list logo
