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

Re: Add switches for DELIMITER and NULL in pg_dump COPY

From: Greg Stark <gsstark(at)mit(dot)edu>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Add switches for DELIMITER and NULL in pg_dump COPY
Date: 2006-03-08 17:03:07
Message-ID: 87wtf4na2c.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
David Fetter <david(at)fetter(dot)org> writes:

> Not everybody's editor/mailer/whatever does this right, and it makes
> things fragile.  Another way to do this is to change the delimter to a
> printable character like '|', but that raises hackles, too.

Frankly if you're passing you data through an editor/mailer/whatever you don't
trust then your setup is already fragile. At least if you're using tabs then
you find out about these problems. Tiptoeing around the untrustworthy process
just means that it'll fail randomly (and unpredictably) when other characters
appear in the data that the software doesn't handle.

There are certainly cases where you'll need to do this to interface with other
(amateurish) software. But pg_dump isn't for that at all. Even COPY isn't a
general purpose data formatter. To interface with other software not using a
standard format you're going to have to pass the data through Perl or
something like that anyways.

-- 
greg


In response to

pgsql-hackers by date

Next:From: Ben ChelfDate: 2006-03-08 17:20:24
Subject: Re: Coverity Open Source Defect Scan of PostgreSQL
Previous:From: Simon RiggsDate: 2006-03-08 16:41:34
Subject: Re: problem with large maintenance_work_mem settings and

pgsql-patches by date

Next:From: Andreas PflugDate: 2006-03-08 18:27:20
Subject: Re: CREATE SYNONYM ...
Previous:From: David FetterDate: 2006-03-08 16:29:55
Subject: Re: Add switches for DELIMITER and NULL in pg_dump COPY

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