Re: [GENERAL] Tabbed data in tab-separated output
On Thu, Jan 04, 2007 at 12:16:17AM -0800, [EMAIL PROTECTED] wrote: > On Wed, Jan 03, 2007 at 10:31:46PM -0600, mike wrote: > > How are you attempting to restore the table after using psql? Psql > > insert statements? Pgdump? COPY FROM? > > Actually, right now I feed the dump file into a program which mangles > it and analyzes it in various ways. It will eventually be fed into > psql for restoration elsewhere. The problem isn't restoring it. It's > not knowing how to tell which tabs are field separators and which are > part of the data. psql is prety dumb that way, being designed for people not programs. I think recent versions will escape the tab. I suggest you use \copy instead, which on recent versions will allow you to copy from a query. Alternativly, use a delimiter that doesn't exist in your data. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [GENERAL] Tabbed data in tab-separated output
On Wed, Jan 03, 2007 at 10:31:46PM -0600, mike wrote: > How are you attempting to restore the table after using psql? Psql > insert statements? Pgdump? COPY FROM? Actually, right now I feed the dump file into a program which mangles it and analyzes it in various ways. It will eventually be fed into psql for restoration elsewhere. The problem isn't restoring it. It's not knowing how to tell which tabs are field separators and which are part of the data. > On Wed, 2007-01-03 at 17:59 -0800, [EMAIL PROTECTED] wrote: > > pg_dump apparently is smart enough to print embedded tabs as escaped > > chars, but not psql. Is there a fix for this? I thought of reverting > > to standard output, without the -t option, and analyzing the first two > > lines to tell exactly how many spaces are assigned to each column, but > > that gives me the shudders. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Tabbed data in tab-separated output
How are you attempting to restore the table after using psql? Psql insert statements? Pgdump? COPY FROM? Mike On Wed, 2007-01-03 at 17:59 -0800, [EMAIL PROTECTED] wrote: > I have a table which has a few VARCHAR columns whose first character > is a tab. If I run pg_dump on this table, it outputs data like this: > > 43158 \t555-12123 > > where the two embedded white spaces are actually tabs. > > If I use psql to execute SQL to dump parts of the table, like this: > > psql -qtA -f '\t' -U xyzzy xyzzy -c 'select ... >/tmp/xxx > > I get this: > > 43158 310-319-1333, x1070 3 > > where that initial embeded white space represents two tabs. When I > use psql to restore this data, it thinks the 2nd column is empty and > complains that the third column is the wrong type. > > pg_dump apparently is smart enough to print embedded tabs as escaped > chars, but not psql. Is there a fix for this? I thought of reverting > to standard output, without the -t option, and analyzing the first two > lines to tell exactly how many spaces are assigned to each column, but > that gives me the shudders. > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Tabbed data in tab-separated output
I have a table which has a few VARCHAR columns whose first character is a tab. If I run pg_dump on this table, it outputs data like this: 43158 \t555-12123 where the two embedded white spaces are actually tabs. If I use psql to execute SQL to dump parts of the table, like this: psql -qtA -f '\t' -U xyzzy xyzzy -c 'select ... >/tmp/xxx I get this: 43158 310-319-1333, x1070 3 where that initial embeded white space represents two tabs. When I use psql to restore this data, it thinks the 2nd column is empty and complains that the third column is the wrong type. pg_dump apparently is smart enough to print embedded tabs as escaped chars, but not psql. Is there a fix for this? I thought of reverting to standard output, without the -t option, and analyzing the first two lines to tell exactly how many spaces are assigned to each column, but that gives me the shudders. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
