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

Re: Add switches for DELIMITER and NULL in pg_dump COPY

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 16:14:54
Message-ID: 20060308161454.GI14881@fetter.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Wed, Mar 08, 2006 at 11:03:00AM -0500, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > From the earlier discussion, it appears that there is a variety of
> > opinions on what the COPY delimiter should be in pg_dump.  This
> > patch allows people to set it and the NULL string.
> 
> Did anyone provide a convincing use case for this?

I've had one so far, and it was enough to cause me to make a special
patched version of pg_dump.  To get some idea of how drastic that was,
consider that I think it's generally bad practice to compile from
source because it can take you too far off the "generally supported
software" map.  The case I had was making a database with a schema and
initial data whose dump output gets checked into a source code
management system.  Those initial data sets, which can change--for
example when the corresponding ISO codes do--may be in many different
tables, so the easiest way to do this is to make the dump file as easy
as possible to edit.

> It's of zero value from the perspective of pg_dump itself; the only
> possible argument is that it makes it easier for program-foo to
> parse the output of pg_dump.  But I don't see any programs around to
> parse arbitrary SQL scripts, especially not the pretty-PG-specific
> scripts that pg_dump emits.

It's less about program-foo parsing than about multi-table data
management, as above.  However, I'm sure that there are people who
will find other uses for it.

> I think it much more likely that people needing this sort of thing would
> be using something like "psql -c 'copy foo to stdout'", so as to get the
> data without any added overhead.

The one-table-at-a-time approach is quite error-prone for large
numbers of tables and/or large data sets.

> So this seems like mere creeping featurism to me.  pg_dump has too
> many switches already.

I've been careful to see to it that only people who use the switches
are affected by it.  I am also volunteering to do ongoing maintenance
of this feature. :)

Cheers,
D
-- 
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2006-03-08 16:20:39
Subject: Re: [PATCHES] Add switches for DELIMITER and NULL in pg_dump COPY
Previous:From: Jim C. NasbyDate: 2006-03-08 16:12:19
Subject: Re: Merge algorithms for large numbers of "tapes"

pgsql-patches by date

Next:From: David FetterDate: 2006-03-08 16:20:39
Subject: Re: [PATCHES] Add switches for DELIMITER and NULL in pg_dump COPY
Previous:From: Neil ConwayDate: 2006-03-08 16:10:04
Subject: Re: [PATCHES] Add switches for DELIMITER and NULL in pg_dump COPY

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