This has been saved for the 7.6 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Tom Lane wrote:
David F. Skoll [EMAIL PROTECTED] writes:
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t
Hi,
This is a response to several messages:
1) Copyright notice: I have no problem having this removed, although it
would be nice to credit me somewhere in a comment.
2) I put most of the code in a separate file so that if the patch is
rejected, it's easy for me to maintain a forked copy. If
David F. Skoll wrote:
Hi,
This is a response to several messages:
1) Copyright notice: I have no problem having this removed, although it
would be nice to credit me somewhere in a comment.
We credit in the commit message, and in the release notes so it will
always be seen.
2) I put
On Wed, 21 Jul 2004, Bruce Momjian wrote:
Even though I suggested it, I am afraid this is just too confusing an API.
How about this:
pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t t1 -n s1
David F. Skoll [EMAIL PROTECTED] writes:
How about this:
pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t t1 -n s1-- Dump t1 in s1
pg_dump -t t1 -t t2 -n s1 --
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all. It might be simpler to extend the -t switch to
accept:
pg-dump -t 's1.*'
rather than using a -n
David F. Skoll [EMAIL PROTECTED] writes:
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all.
Sure we do --- for backwards compatibility if nothing else.
It
Yes, the reason it would be nice for me is that currently if you want to
dump two specific, related tables from your db, there's no way to do it
with pg_dump within the one transactions (ie. maintaining integrity). I
guess I'm in favour of -t -t but not -T depending on the complexity of
it.
Tom Lane said:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Well, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(
It would have been a lot easier to approve it if it'd arrived on June
30 rather than July 6 :-(. However,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
One problem with this patch is that there's no way to dump multiple
tables in different schemas. Does this matter? It's a bit
non-orthogonal...
Yeah. With the combination of -n and -t you can pull a specific table,
but as soon as you allow
On Tue, 20 Jul 2004, Tom Lane wrote:
(BTW, does the patch handle multiple -n switches?)
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of
David F. Skoll wrote:
On Tue, 20 Jul 2004, Tom Lane wrote:
(BTW, does the patch handle multiple -n switches?)
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers;
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we
On Wed, 21 Jul 2004, Christopher Kings-Lynne wrote:
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if
Gavin Sherry wrote:
On Wed, 21 Jul 2004, Christopher Kings-Lynne wrote:
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
Philip Warner wrote:
At 12:59 PM 21/07/2004, Bruce Momjian wrote:
Yes, no need for it. We discourage that.
Might be polite, not to mention legally required, to check with the author
of the patch first.
To be clear, we will ask the author if we can remove it, and if they say
no, we will
Does anyone have opinions on including this in 7.5? I see it first
appeared on July 6, six days after feature freeze.
---
David F. Skoll wrote:
Attached is a patch against pg_dump version 7.4.3 that permits
multiple -t
I see one vote in favor of its inclusion on the grounds it is a bug not
to support multiple -t parameters. However, is someone objects I will
have to hold it for 7.6. It needs SGML doc additions which I will do
myself.
Your patch has been added to the PostgreSQL unapplied patches list at:
I see one vote in favor of its inclusion on the grounds it is a bug not
to support multiple -t parameters. However, is someone objects I will
have to hold it for 7.6. It needs SGML doc additions which I will do
myself.
Well, I guess I'm against it based on the rules of feature freeze,
even
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Well, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(
It would have been a lot easier to approve it if it'd arrived on June 30
rather than July 6 :-(. However, I do believe that
Well, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(
It would have been a lot easier to approve it if it'd arrived on June 30
rather than July 6 :-(. However, I do believe that David originally
submitted a slightly-too-late
Attached is a patch against pg_dump version 7.4.3 that permits
multiple -t switches so that you can select more than one table (but
less than all) to dump.
It also adds a -T switch (long name --exclude-table) that says
*not* to dump a specific table. So:
pg_dump -t table1 -t table2 db
22 matches
Mail list logo