Skip site navigation (1) Skip section navigation (2)

Bug#61519: Copy does not work with special characters? (fwd)

From: "Oliver Elphick" <olly(at)lfix(dot)co(dot)uk>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Bug#61519: Copy does not work with special characters? (fwd)
Date: 2000-04-01 14:02:44
Message-ID: 200004011402.e31E2iR04740@linda.lfix.co.uk (view raw or flat)
Thread:
Lists: pgsql-bugs
Can someone suggest a solution for this problem in 6.5.3, please?

------- Forwarded Message

Date:    Sat, 01 Apr 2000 11:57:30 +0200
From:    Torsten Landschoff <torsten(at)debian(dot)org>
To:      submit(at)bugs(dot)debian(dot)org
Subject: Bug#61519: Copy does not work with special characters?

Package: postgresql
Version: 6.5.3-15

Hi Oliver, 

I was told about a problem in PostgreSQL (seems to be an upstream bug but
I am not sure). Look at this:

template1=> create table foo (bar varchar(30), baz varchar(30));
CREATE
template1=> insert into foo values ('this', 'works');
INSERT 21328 1
template1=> insert into foo values ('thiß', 'not');
template1'> insert into foo values ('thiß', 'not');
INSERT 21330 1
template1=> insert into foo values ('this works', 'again');
INSERT 21331 1

See? Why is psql opening a continuation line when inserting 'thiß'?
Now the result is:

template1=> select * from foo;
bar       |baz  
- ----------+-----
this      |works
thiß      |not  
thiß      |not  
this works|again
(4 rows)

??? It was inserted twice just as if Postgres did not have any problem
with it. Perhaps psql has a bug? But this only happened to me when I 
tried to reproduce the bug which is interesting for us. We are inserting
data using the ODBC interface and it works even with special chars.
But we are having problems making a backup of that stuff:

torsten(at)pulsar:~ $ pg_dump template1
\connect - torsten
CREATE TABLE "foo" (
        "bar" character varying(30),
        "baz" character varying(30));
\connect - postgres
CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS
'/usr/lib/postgresql/lib/plpgsql.so' LANGUAGE 'C';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler"
LANCOMPILER 'PL/pgSQL';
\connect - torsten
COPY "foo" FROM stdin;
this    works
thiß
thiß
this works      again
\.

Now where did the second column go when exporting? We had a lot of work
with reconstructing the contents of one of our databases (we lost it
due to a disk crash).

Right, we should have tested our backups but they worked with the tested
data set...

Oliver, can you please forward this upstream?

Thanks

    Torsten

- -- 
Torsten Landschoff           Bluehorn(at)IRC               <torsten(at)debian(dot)org>
           Debian Developer and Quality Assurance Committee Member


------- End of Forwarded Message


-- 
Oliver Elphick                                Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "Therefore, if anyone is in Christ, he is a new   
      creation; the old has gone, the new has come."   
                      II Corinthians 5:17  



pgsql-bugs by date

Next:From: wernerDate: 2000-04-01 19:31:50
Subject: --enable-locale doesn't work
Previous:From: Peter EisentrautDate: 2000-03-09 00:38:48
Subject: Re: [BUGS] pg_dumpall

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group