parallel.c has an "aborting" flag that's entirely useless, as it's
set only during archive_close_connection(), and tested only in places
that are not reached after that. I've confirmed this both by code
reading and by testing. It appears from some of the comments that
there was once an intent to
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
Hi,
With the following test case pgdump creates a corrupt tar file i.e.
CREATE DATABASE dump_test;
> \c dump_test
> CREATE TABLE test_table1 (int1 int);
> INSERT INTO test_table1 (SELECT * FROM generate_series(1, 1000));
> \! pg_dump -F t -f dump_test.tar dump_test
Debugging shows that pg_dump
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.
--
Is there anyone who written a patch for a multiple pg_dump like:
pg_dump -t table1 table2 ... tableN dbname
Regards Enrico
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to
21 matches
Mail list logo
