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> |
Subject: | Re: Proposal: new pg_dump options --copy-delimiter and --copy-null |
Date: | 2006-01-27 03:41:45 |
Message-ID: | 20060127034145.GD11803@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > I have seed database scripts quasi-generated from pg_dump which
> > include COPY statements, but the data is hard to edit (especially
> > cut & paste operations) when the COPY delimiter is some
> > non-visible character like \t.
>
> This seems like an awfully weak use-case for adding to pg_dump's
> already overly complicated feature set.
Those who don't use it will never see it.
> The difficulty of parsing COPY output is not simplified by making
> the delimiter variable --- more likely the reverse.
It's fairly straight-forward.
> Furthermore, it's quite unclear why you'd use pg_dump at all to
> generate a data file that you intend to feed to some other program.
In my case, it's about being copy/paste friendly.
> Seems to me that "psql -c 'COPY ...'" is a more likely front-end for
> such a process.
Actually, it's not. I'm attaching my preliminary patch, as I see I
haven't explained it well enough.
Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 415 235 3778
Remember to vote!
Attachment | Content-Type | Size |
---|---|---|
pg_dump_copy.diff | text/plain | 5.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2006-01-27 03:48:11 | Re: VACUUM Question |
Previous Message | Tom Lane | 2006-01-27 03:17:05 | Re: Proposal: new pg_dump options --copy-delimiter and --copy-null |