On Oct 18, 2005, at 12:52 AM, Scott Marlowe wrote:What problems have you run into lately? And could pg_restore fix them, or were they too hairy?the only issues I have are when not doing a full dump/restore of a DB -- ie only pulling in data into an existing table structure. the ordering is not gu
Title: RE: [GENERAL] fine tuned database dump/reload?
-Original Message-
From: [EMAIL PROTECTED] on behalf of Vivek Khera
Sent: Mon 10/17/2005 3:35 PM
To: Postgres General
Subject: Re: [GENERAL] fine tuned database dump/reload?
On Oct 17, 2005, at 9:34 AM, Dan Armbrust wrote
On Oct 17, 2005, at 9:34 AM, Dan Armbrust wrote:
Jim C. Nasby wrote:
> pg_dump handles table ordering properly.
>
Maybe I missed something then, because it didn't last time I tried
to move some data. I had to drop my foreign keys before I could
reload it.
This is my experience as well.
Douglas McNaught <[EMAIL PROTECTED]> writes:
> Dan Armbrust <[EMAIL PROTECTED]> writes:
>> Maybe I missed something then, because it didn't last time I tried to
>> move some data. I had to drop my foreign keys before I could reload
>> it.
> What version was this? Older versions definitely had so
Dan Armbrust <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
> > pg_dump handles table ordering properly.
> >
>
> Maybe I missed something then, because it didn't last time I tried to
> move some data. I had to drop my foreign keys before I could reload
> it.
What version was this? Older ve
Jim C. Nasby wrote:
> pg_dump handles table ordering properly.
>
Maybe I missed something then, because it didn't last time I tried to
move some data. I had to drop my foreign keys before I could reload it.
Dan
--
Daniel Armbrust
Biomedical Informatics
Mayo Clin
pg_dump handles table ordering properly.
On Fri, Oct 14, 2005 at 10:24:55AM -0500, Dan Armbrust wrote:
> Jim C. Nasby wrote:
> >Since no one else has mentioned it, there has been discussion this week
> >on one of the lists (probably -general or -hackers) about expanding the
> >capabilities of pg_d
Jim C. Nasby wrote:
Since no one else has mentioned it, there has been discussion this week
on one of the lists (probably -general or -hackers) about expanding the
capabilities of pg_dump. I've advocated for allowing a file that
specifies what objects to dump and what kind of filtering to apply t
Since no one else has mentioned it, there has been discussion this week
on one of the lists (probably -general or -hackers) about expanding the
capabilities of pg_dump. I've advocated for allowing a file that
specifies what objects to dump and what kind of filtering to apply to
the name. Allowing f
The TODO has has an open item to all multiple -t options and other
complexity.
---
Dan Armbrust wrote:
> Dan Armbrust wrote:
> > Bricklen Anderson wrote:
> >
> >>
> >> pg_dump --help
> >> ...
> >> -n, --schema=SCHEMA
Dan Armbrust wrote:
Is there a better way to do this? Is there a flag I could specify for
psql that would cause it to output INSERT or COPY statements as a result
of a query - select * from foo where terminologyId=foo? Then I could
just have 15 select statements batched up in a file, and pi
My use case is not so much for database backup purposes as it is for
fine grained export and import.
Our database schema consists of 15 tables that represent a terminology.
Each database can hold multiple terminologies - every table has a
terminologyId column which distinguishes one termino
On 10/11/05, Dan Armbrust wrote::
> Now I'm just filling the mailing list with mis-information. It actually> ignores all but the last -t flag - so this only allows me to specify one> table at a time, rather than several tables.
There's always the low-tech option of:
for table in `cat /tmp/tabl
Dan Armbrust wrote:
>>
> Now I'm just filling the mailing list with mis-information. It actually
> ignores all but the last -t flag - so this only allows me to specify one
> table at a time, rather than several tables.
>
> I need to write up my use case so the maintainers can see why I want to
>
Dan Armbrust wrote:
Bricklen Anderson wrote:
pg_dump --help
...
-n, --schema=SCHEMA dump the named schema only
-s, --schema-onlydump only the schema, no data
-t, --table=TABLEdump the named table only
...
Just after I sent the e-mail, I realized that I forgot that
Bricklen Anderson wrote:
pg_dump --help
...
-n, --schema=SCHEMA dump the named schema only
-s, --schema-onlydump only the schema, no data
-t, --table=TABLEdump the named table only
...
Just after I sent the e-mail, I realized that I forgot that I saw that
option -
Dan Armbrust <[EMAIL PROTECTED]> writes:
> Does postgresql have any facility to dump anything more fine grained
> than a database to a text file?
You can dump a single table with the -t option. Right now you can't
specify an arbitrary set of tables to dump.
> For example, to mention a bad word,
Dan Armbrust wrote:
> Does postgresql have any facility to dump anything more fine grained
> than a database to a text file?
>
> For example, to mention a bad word, MySQL's dump command allows you to
> specify individual tables to dump
> PostgreSQL's pg_dump command seems rather limited in its
On Tue, 2005-10-11 at 11:20, Dan Armbrust wrote:
> Does postgresql have any facility to dump anything more fine grained
> than a database to a text file?
>
> For example, to mention a bad word, MySQL's dump command allows you to
> specify individual tables to dump - and not only that - you can a
Does postgresql have any facility to dump anything more fine grained
than a database to a text file?
For example, to mention a bad word, MySQL's dump command allows you to
specify individual tables to dump - and not only that - you can also
specify a SQL query that must be satisfied for a row
20 matches
Mail list logo
