Asif Naeem writes:
> With the following test case pgdump creates a corrupt tar file i.e.
Ooops :-(. Thanks for the report!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Neil Conway wrote:
I would be OK with just ignoring this case, but on reflection I would
prefer removing the "-t schema.table" syntax. Removing the feature
resolves the quoting issue and also simplifies pg_dump's behavior. We
lose the ability to dump table t1 in schema s1 and table t2 in schema s2
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
>> Just to be clear: what I understand the logic to be is "OR" across
>> multiple switches of the same type, but "AND" across switches of
>> two types.
> If I understand you correctly, you're suggesting th
On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
> Just to be clear: what I understand the logic to be is "OR" across
> multiple switches of the same type, but "AND" across switches of
> two types.
If I understand you correctly, you're suggesting that we should only
report an error if none of th
Neil Conway <[EMAIL PROTECTED]> writes:
> So the behavior would be that suggested earlier by David Skoll:
>> 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
On Mon, 2005-01-17 at 00:54 -0500, Tom Lane wrote:
> -t s1.t1
> [...] without any quoting rules it would then become impossible to
> deal with names containing dots.
Ah, yeah -- sorry, I was focusing on case conversion rather than quoting
in general.
> Are we willing to blow off that case?
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote:
>> A little further down-thread there was some discussion of also allowing
>> wild cards in the individual switches,
> Is this actually useful behavior?
Possibly not. It's been requested often enough, bu
On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote:
> A little further down-thread there was some discussion of also allowing
> wild cards in the individual switches, eg
>
> -t 's1.*'
>
> (This would differ from '-n s1' in that a -t switch would restrict the
> dump to tables only, whereas -n
Neil Conway <[EMAIL PROTECTED]> writes:
> Something like the design elaborated here:
> http://archives.postgresql.org/pgsql-patches/2004-07/msg00374.php
> looks good to me, and would be preferrable to Andreas' patch IMHO.
> Unless I'm missing something, I don't see a patch from David Skoll in
> t
Neil Conway wrote:
> On Sun, 2005-01-16 at 23:42 -0500, Bruce Momjian wrote:
> > I don't remember this patch.
>
> http://archives.postgresql.org/pgsql-patches/2004-07/msg00331.php
>
> > How is it related to the other pg_dump
> > patches in the 8.1 pathces queue?
>
> I missed the July '04 discuss
On Sun, 2005-01-16 at 23:42 -0500, Bruce Momjian wrote:
> I don't remember this patch.
http://archives.postgresql.org/pgsql-patches/2004-07/msg00331.php
> How is it related to the other pg_dump
> patches in the 8.1 pathces queue?
I missed the July '04 discussion about the other patches for impro
Neil Conway wrote:
> On Fri, 2005-01-14 at 16:24 +0100, Andreas Joseph Krogh wrote:
> > http://dev.officenet.no/~andreak/pg_dump.c.diff
>
> Looks good, except for some minor code cleanups and doc updates. Barring
> any objections, I'll clean it up and apply it once we branch 8.0. I
> suppose for c
On Fri, 2005-01-14 at 16:24 +0100, Andreas Joseph Krogh wrote:
> http://dev.officenet.no/~andreak/pg_dump.c.diff
Looks good, except for some minor code cleanups and doc updates. Barring
any objections, I'll clean it up and apply it once we branch 8.0. I
suppose for consistency we ought to allow mu
Here it is:
http://dev.officenet.no/~andreak/pg_dump.c.diff
Many Thanks :)))
Enrico
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Friday 14 January 2005 14:54, Enrico wrote:
> >Yes, I have such a patch lying around(pg_dump -t table1 -t table2 ...
> > dbname).
> >
> >It's for 7.4, but shouldn't be hard to port to 8.0.
>
> Oh wonderful, how can I see that? I'm working with 7.4.x version.
Actually, it's for 7.4beta3, but sho
yo mero wrote:
you can use this in BASH:
for a in table1 table2 tableN
do
echo $a
pg_dump -t $a dbname > $a.sql
done
works fine
leonel
Yes I wrote that, but I wanted to know if is possible to do that without
a bash script,
Regards Enrico
---(end of broadcast)-
Yes, I have such a patch lying around(pg_dump -t table1 -t table2 ... dbname).
It's for 7.4, but shouldn't be hard to port to 8.0.
Oh wonderful, how can I see that? I'm working with 7.4.x version.
Thanks Enrico
---(end of broadcast)---
TIP 1: subs
On Friday 14 January 2005 11:45, Enrico wrote:
> Is there anyone who written a patch for a multiple pg_dump like:
>
> pg_dump -t table1 table2 ... tableN dbname
Yes, I have such a patch lying around(pg_dump -t table1 -t table2 ... dbname).
It's for 7.4, but shouldn't be hard to port to 8.0.
--
18 matches
Mail list logo
