Re: Proposal: new pg_dump options --copy-delimiter and --copy-null
| От | David Fetter |
|---|---|
| Тема | Re: Proposal: new pg_dump options --copy-delimiter and --copy-null |
| Дата | |
| Msg-id | 20060127034145.GD11803@fetter.org обсуждение исходный текст |
| Ответ на | Re: Proposal: new pg_dump options --copy-delimiter and --copy-null (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Proposal: new pg_dump options --copy-delimiter and --copy-null
Re: Proposal: new pg_dump options --copy-delimiter and Re: Proposal: new pg_dump options --copy-delimiter and --copy-null |
| Список | pgsql-hackers |
On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote: > David Fetter <david@fetter.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@fetter.org http://fetter.org/ phone: +1 415 235 3778 Remember to vote!
Вложения
В списке pgsql-hackers по дате отправления: