Re: [HACKERS] COPY problems with psql / libpq
От | Oliver Elphick |
---|---|
Тема | Re: [HACKERS] COPY problems with psql / libpq |
Дата | |
Msg-id | 200001201844.SAA10272@linda.lfix.co.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] COPY problems with psql / libpq (Patrick Welche <prlw1@newn.cam.ac.uk>) |
Список | pgsql-hackers |
Patrick Welche wrote: >On Thu, Jan 20, 2000 at 09:22:16AM -0800, Alfred Perlstein wrote: >> * Patrick Welche <prlw1@newn.cam.ac.uk>[000120 09:10] wrote: >> > On Thu, Jan 20, 2000 at 11:02:31AM -0500, Tom Lane wrote: >> > > >> > >It sure sounds like psql is failing to recognize the trailing \. >> > > of the COPY data. >> > >> > Precisely what I sawyesterday (cf Subject: pg_dump disaster) - but what >> > does one do about it? >> >> Is this with a recent snapshot or6.5.3 using libpq? > >For me, it's using yesterday's cvs'd source - but I obviously can't speak >for Oliver. This morning's. >> Either way, you should check the contents of the send buffer, please let >> me know if there is data queued in it. Youcan include the 'internal' >> header for libpq (libpq-int.h?) to get at the send buffer. > >That will take a while. Inthe meantime, just pg_dumpall something and try >to read the output back in. I do have ^M's in some of the text columnsif >that matters. I can't do that, because pg_dump seems to be broken if there are tables with foreign key constraints. (See a separate message.) -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "Neither is there salvation in any other; for thereis none other name under heaven given among men, whereby we must be saved." Acts 4:12
В списке pgsql-hackers по дате отправления: