Re: [HACKERS] copy from stdin; bug?
Nathan Myers wrote: [ ... ] Not true. There are Debian source packages, Where are they ? I'm *quite* interested ! and taking the source package from Debian 2.x, x2 (woody/sid), you can easily build it on Debian 2.2 (potato). In fact, it seems likely that a 2.2 (potato) packaging of 7.1 should be available from somebody else anyhow. Oliver, do you plan to make the woody 7.1 package depend on any other package versions not in potato? If not, you can just use the 7.1 package directly on your Debian 2.2 system. Oliver Elphick seems awfully busy and once said that 7.1 required a *lot* of packaging ... Better not bug him right now ... -- Emmanuel Charpentier
Re: [HACKERS] copy from stdin; bug?
Emmanuel Charpentier wrote: Oliver Elphick seems awfully busy and once said that 7.1 required a *lot* of packaging ... Better not bug him right now ... I'm working on it at the moment. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For the eyes of the LORD run to and fro throughout the whole earth, to show himself strong in the behalf of them whose heart is perfect toward him..." II Chronicles 16:9
Re: [HACKERS] copy from stdin; bug?
On Wed, Jan 17, 2001 at 10:34:45PM +0100, Emmanuel Charpentier wrote: Nathan Myers wrote: Not true. There are Debian source packages, Where are they ? I'm *quite* interested ! and taking the source package from Debian 2.x, x2 (woody/sid), you can easily build it on Debian 2.2 (potato). They're as near as "apt-get source postgresql", once you have edited /etc/apt/sources.list to point to the package repositories you want, and have run "apt-get update" to synchronize with those repositories. Under the best circumstances, "apt-get source -b postgresql" will download the sources and build a ".deb" tailored for your system, much as in the BSD "ports" system. (I say "best circumstances" because the package or the build process may depend on tools and "-dev" packages you have not "apt-get install"'ed yet, and because you might prefer to tinker with configuration options before building.) I'm sure once Oliver has prepared a 7.1 Debian package he will announce it here. (This is getting dangerously Debian-specific.) Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] copy from stdin; bug?
Re On Tue, 16 Jan 2001, Tatsuo Ishii wrote: The encoding of your databases are all UNICODE. So you need to input data as UTF-8 in this case. I guess you are trying to input ISO-8859-1 encoded data that is the source of the problem. Here are possible solutions: 1) input data as UTF-8 :) 2) crete a new databse using encoidng LATIN1. createdb -E LATIN1... yes, this will be the sollution... 3) upgrade to 7.1 that has the capability to do an automatic conversion between UTF-8 and ISO-8859-1. i like to use deb packages and to use 7.1 i would have to upgrade to woody (or even sid)... thank you for your quick help!!! Udv tRehak E-Mail: Tom Rehak [EMAIL PROTECTED]
Re: [HACKERS] copy from stdin; bug?
On Wed, Jan 17, 2001 at 01:40:58AM +0100, Rehak Tamas wrote: 3) upgrade to 7.1 that has the capability to do an automatic conversion between UTF-8 and ISO-8859-1. i like to use deb packages and to use 7.1 i would have to upgrade to woody (or even sid)... Not true. There are Debian source packages, and taking the source package from Debian 2.x, x2 (woody/sid), you can easily build it on Debian 2.2 (potato). In fact, it seems likely that a 2.2 (potato) packaging of 7.1 should be available from somebody else anyhow. Oliver, do you plan to make the woody 7.1 package depend on any other package versions not in potato? If not, you can just use the 7.1 package directly on your Debian 2.2 system. (Apologies to the rest for the Debian jargon.) Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] copy from stdin; bug?
Hello On Mon, 15 Jan 2001, Tatsuo Ishii wrote: Can you show me your database name and the output from 'psql -l'? yes, here are the output: datname |datdba|encoding|datpath -+--++- template1|31| 5|template1 map | 1003| 5|map helyes | 1003| 5|helyes i found that if i put a space behind the letters ([o with accent][a-z][\t]) before the tab, it works correct... but without the space it corrupt the database... Udv tRehak E-Mail: Tom Rehak [EMAIL PROTECTED]
Re: [HACKERS] copy from stdin; bug?
yes, here are the output: datname |datdba|encoding|datpath -+--++- template1|31| 5|template1 map | 1003| 5|map helyes | 1003| 5|helyes i found that if i put a space behind the letters ([o with accent][a-z][\t]) before the tab, it works correct... but without the space it corrupt the database... The encoding of your databases are all UNICODE. So you need to input data as UTF-8 in this case. I guess you are trying to input ISO-8859-1 encoded data that is the source of the problem. Here are possible solutions: 1) input data as UTF-8 2) crete a new databse using encoidng LATIN1. createdb -E LATIN1... 3) upgrade to 7.1 that has the capability to do an automatic conversion between UTF-8 and ISO-8859-1. -- Tatsuo Ishii
[HACKERS] copy from stdin; bug?
Hello i don't know, whether it is a real bug or what, has been fixed or not, but i can't find any info about it: i try to fill my table from a file using copy from stdin and postgresql corrupt the table. This happen if before the tab or end of line there is word that has a non-standard letter like o with accent and then an ordinary lette [a-z]. and now i reproduced this error if that o is at the and of the word. in these cases that word and the next one get into the same field... why does it happen? thanks tRehak E-Mail: Tom Rehak [EMAIL PROTECTED]
Re: [HACKERS] copy from stdin; bug?
Rehak Tamas [EMAIL PROTECTED] writes: i try to fill my table from a file using copy from stdin and postgresql corrupt the table. This happen if before the tab or end of line there is word that has a non-standard letter like o with accent and then an ordinary lette [a-z]. and now i reproduced this error if that o is at the and of the word. in these cases that word and the next one get into the same field... Sounds to me like a multibyte-character translation problem. What encoding do you have set for the database? What have you told it the client encoding is? regards, tom lane
