"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
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
> 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
"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 migh
On Tue, 2002-08-13 at 19:54, Christopher Kings-Lynne wrote:
> > 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 conv
> 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
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
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
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 pos
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 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 INSER
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 selec
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 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
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 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 w
16 matches
Mail list logo
