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
"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
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 swi
"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, 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 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 p
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 t
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 wi
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
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 critic
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 occasiona
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 custo
Tom Lane wrote:
> 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 :-
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 ta
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 a
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 :-(.
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. I
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 version
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 th
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 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:
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
22 matches
Mail list logo
