We have a patch for pg_dump which adds a possibility to dump
a part of table, for example:
dump Top.Science.Astronomy heirarchy from dmoz catalog
pg_dump -d -t dmoz -w select * from dmoz where path @ 'Top.Science.Astronomy' dmoz
We found it's very useful. We'd like to extend it to use also
On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote:
We have a patch for pg_dump which adds a possibility to dump
a part of table, for example:
dump Top.Science.Astronomy heirarchy from dmoz catalog
pg_dump -d -t dmoz -w select * from dmoz where path @ 'Top.Science.Astronomy' dmoz
We
On 13 Aug 2002, Rod Taylor wrote:
On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote:
We have a patch for pg_dump which adds a possibility to dump
a part of table, for example:
dump Top.Science.Astronomy heirarchy from dmoz catalog
pg_dump -d -t dmoz -w select * from dmoz where path @
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
On Tue, 13 Aug 2002, Tom Lane wrote:
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
On Tue, 2002-08-13 at 20:24, Tom Lane wrote:
What would seem to make sense is adding a WHERE-clause option to
COPY TO, and then you could go
COPY table TO 'myfile' WHERE ...
What about :
COPY table TO 'myfile' [ WHERE cond ] [ AS INSERT [ WITH COLUMN ] ];
to get the data as INSERT
Actually, loading all this stuff into COPY is not the way to go, I
think.
Informix had:
UNLOAD TO 'filename'
SELECT ...
I have to admit, this is a superior way to do thing compared to what we
have. Is is possible for us to get:
COPY TO 'filename'
SELECT ...
On Wed, 2002-08-14 at 00:03, Bruce Momjian wrote:
Actually, loading all this stuff into COPY is not the way to go, I
think.
Informix had:
UNLOAD TO 'filename'
SELECT ...
I have to admit, this is a superior way to do thing compared to what we
have. Is is possible for
Hannu Krosing wrote:
On Wed, 2002-08-14 at 00:03, Bruce Momjian wrote:
Actually, loading all this stuff into COPY is not the way to go, I
think.
Informix had:
UNLOAD TO 'filename'
SELECT ...
I have to admit, this is a superior way to do thing compared to what we
Bruce Momjian [EMAIL PROTECTED] writes:
Clearly, we should shoot for something that leverages the existing
SELECT code rather than hang more clauses off of COPY.
Yeah, that's a good point. COPY IN is still a special case, I think,
but seems like COPY OUT could be reimplemented as a special
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
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Tell you what I'd kill for:
pg_dump -t users_\* db users.sql
Yeah, I was just about to start working on pg_dump's -t switch.
It absolutely *must* be made schema-aware for 7.3 (-t schema.table
doesn't work today) and it seems like we might as
Yeah, I was just about to start working on pg_dump's -t switch.
It absolutely *must* be made schema-aware for 7.3 (-t schema.table
doesn't work today) and it seems like we might as well try to allow
wildcard support. Another thought I had was to accept multiple -t
switches, eg pg_dump -t
Scott Shattuck [EMAIL PROTECTED] writes:
I'd also kill for pg_restore --ignore-existing-objects so I could
run the darn thing against a database that's already got pl/pgsql
installed in template1 and the dump file wants to install it again etc.
In general, I think it's a mistake for
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What about a switch to set schema search path as well?
I'm leaning to the thought that this is a bad idea, and that pg_dump
should act in a way that's search-path-independent. But I need to
think more.
You could also just have the tables
15 matches
Mail list logo
