Re: db partial dumping with pg_dump
От | Tom Lane |
---|---|
Тема | Re: db partial dumping with pg_dump |
Дата | |
Msg-id | 26181.1029252278@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: db partial dumping with pg_dump (Oleg Bartunov <oleg@sai.msu.su>) |
Ответы |
Re: db partial dumping with pg_dump
Re: db partial dumping with pg_dump Re: db partial dumping with pg_dump |
Список | pgsql-hackers |
This patch seems extremely messy to me. Unless I'm missing something, -w just plain fails except when you are dumping a specific table (ie, -t must be given as well). And heaven help you if you specify a different table in -t than the one -w is selecting from. This isn't well thought out. I'm not at all convinced that such a thing belongs in pg_dump anyway. It'd be more useful as a manually-invokable feature, I think. You can almost do this in psql withselect * from table where something\g outfile but I don't think you can get psql to emit the data in a form that can be reloaded reliably (it won't quote data characters that look the same as column delimiters, for instance). What would seem to make sense is adding a WHERE-clause option to COPY TO, and then you could goCOPY table TO 'myfile' WHERE ... We already have column-list support in COPY, so we can already slice the table vertically --- WHERE would let you slice it horizontally, which seems a natural extension. (BTW, has anyone taught psql's \copy about column lists? AFAIR the original patch was only against the backend.) I'm finding it hard to visualize situations where I'd want the extra baggage of pg_dump for something like this. If I want the schema at all, I'll probably want it separate from the data so that I can hack the schema conveniently --- so I'd want to do a "pg_dump -s -t table" and then do the selective copying separately. regards, tom lane
В списке pgsql-hackers по дате отправления: