Re: Add switches for DELIMITER and NULL in pg_dump COPY
От | David Fetter |
---|---|
Тема | Re: Add switches for DELIMITER and NULL in pg_dump COPY |
Дата | |
Msg-id | 20060308161454.GI14881@fetter.org обсуждение исходный текст |
Ответ на | Re: Add switches for DELIMITER and NULL in pg_dump COPY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add switches for DELIMITER and NULL in pg_dump COPY
|
Список | pgsql-hackers |
On Wed, Mar 08, 2006 at 11:03:00AM -0500, Tom Lane wrote: > David Fetter <david@fetter.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@fetter.org http://fetter.org/ phone: +1 415 235 3778 Remember to vote!
В списке pgsql-hackers по дате отправления: