On 12/16/2011 02:43 PM, Greg Smith wrote:
On 12/12/2011 04:35 PM, Andrew Dunstan wrote:
Should all be fixed. Revised patch attached.
There were two successful test results here and only minor things
noted to fix, which are all cleaned up now. This seems ready for a
committer now; I'm just
On 12/12/2011 04:35 PM, Andrew Dunstan wrote:
Should all be fixed. Revised patch attached.
There were two successful test results here and only minor things noted
to fix, which are all cleaned up now. This seems ready for a committer
now; I'm just now sure if you want to do it yourself or ha
On 12/08/2011 09:18 PM, Joachim Wieland wrote:
On Tue, Nov 15, 2011 at 6:14 PM, Andrew Dunstan wrote:
Updated version with pg_restore included is attached.
The patch applies with some fuzz by now but compiles without errors or warnings.
The feature just works, it is not adding a lot of new
On 12/8/11 9:18 PM, Joachim Wieland wrote:
> If you ask pg_restore to restore a section out of an archive which
> doesn't have this section, there is no error and the command just
> succeeds. This is what I expected and I think it's the right thing to
> do but maybe others think that
> there should
On Tue, Nov 15, 2011 at 6:14 PM, Andrew Dunstan wrote:
> Updated version with pg_restore included is attached.
The patch applies with some fuzz by now but compiles without errors or warnings.
The feature just works, it is not adding a lot of new code, basically
it parses the given options and th
On 12/07/2011 11:31 AM, Tom Lane wrote:
Josh Berkus writes:
Note that this feature has the odd effect that some constraints are loaded at
the same time as the tables and some are loaded with the post-data. This is
consistent with how text-mode pg_dump has always worked, but will seem odd t
Josh Berkus writes:
>>> Note that this feature has the odd effect that some constraints are loaded
>>> at the same time as the tables and some are loaded with the post-data.
>>> This is consistent with how text-mode pg_dump has always worked, but will
>>> seem odd to the user. This also raise
>> Note that this feature has the odd effect that some constraints are loaded
>> at the same time as the tables and some are loaded with the post-data. This
>> is consistent with how text-mode pg_dump has always worked, but will seem
>> odd to the user. This also raises the possibility of a f
On Tue, Nov 15, 2011 at 8:19 PM, Joshua Berkus wrote:
>> > Here is a patch for that for pg_dump. The sections provided for are
>> > pre-data, data and post-data, as discussed elsewhere. I still feel that
>> > anything finer grained should be handled via pg_restore's --use-list
>> > functionality.
> > Here is a patch for that for pg_dump. The sections provided for are
> > pre-data, data and post-data, as discussed elsewhere. I still feel that
> > anything finer grained should be handled via pg_restore's --use-list
> > functionality. I'll provide a patch to do the same switch for pg_restore
On Sat, November 12, 2011 8:56 pm, Andrew Dunstan wrote:
>
>
> On 08/26/2011 05:11 PM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> The "--section=data --section=indexes" proposal seems very reasonable
>>> to
>>> me -- more so than "--sections='data indexes'".
>> +1 ... not only easier to code an
Hi Andrew,
On 13/11/2011 02:56, Andrew Dunstan wrote:
Here is a patch for that for pg_dump. The sections provided for are
pre-data, data and post-data, as discussed elsewhere. I still feel that
anything finer grained should be handled via pg_restore's --use-list
functionality. I'll provide a pat
On 08/26/2011 05:11 PM, Tom Lane wrote:
Alvaro Herrera writes:
The "--section=data --section=indexes" proposal seems very reasonable to
me -- more so than "--sections='data indexes'".
+1 ... not only easier to code and less squishily defined, but more like
the existing precedent for other pg
On 09/03/2011 04:49 PM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Oh, I meant just having it create separate custom format files for each
database. As shell scripts all over the world have been doing for years,
but it would be nice if it was simply built in.
I guess it could be done, al
Andrew Dunstan writes:
>> Oh, I meant just having it create separate custom format files for each
>> database. As shell scripts all over the world have been doing for years,
>> but it would be nice if it was simply built in.
>
> I guess it could be done, although I'm not going to do it :-) I'm mor
On 09/01/2011 09:40 PM, Greg Sabino Mullane wrote:
It's off topic. But I think custom format would require a major mangling
to be able to handle a complete cluster. This isn't just a simple matter
of programming, IMNSHO.
Oh, I meant just having it create separate custom format files for each
d
"Greg Sabino Mullane" writes:
>> It's off topic. But I think custom format would require a major mangling
>> to be able to handle a complete cluster. This isn't just a simple matter
>> of programming, IMNSHO.
>
> Oh, I meant just having it create separate custom format files for each
> database. A
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> It's off topic. But I think custom format would require a major mangling
> to be able to handle a complete cluster. This isn't just a simple matter
> of programming, IMNSHO.
Oh, I meant just having it create separate custom format files for
On 08/31/2011 04:03 PM, Alvaro Herrera wrote:
Well, the Unix approach is to use tools that do one thing well to build up more
complex tools. Making pg_dump run some external command to inject things into
the stream seems like the wrong thing given this philosophy. Use pg_dump to get
the bit
Excerpts from Jim Nasby's message of mié ago 31 16:45:59 -0300 2011:
> On Aug 26, 2011, at 5:23 PM, Andrew Dunstan wrote:
> > On 08/26/2011 04:46 PM, Jim Nasby wrote:
> >> On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
> >>> I knew there would be some bike-shedding about how we specify these
On Aug 26, 2011, at 5:23 PM, Andrew Dunstan wrote:
> On 08/26/2011 04:46 PM, Jim Nasby wrote:
>> On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
>>> I knew there would be some bike-shedding about how we specify these things,
>>> which is why I haven't written docs yet.
>> While we're debating
On 08/27/2011 06:56 PM, Greg Sabino Mullane wrote:
Once these new flags and the ability to custom format dump pg_dumpall
is done, I'll have very little left to complain about with pg_dump :)
It's off topic. But I think custom format would require a major mangling
to be able to handle a co
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Well, notwithstanding my well known love of perl, that strikes me as
> spending a pound to save a penny. And custom format dumps rock ;-) Also,
> your recipe above is buggy, BTW. A CREATE INDEX statement might well not
> be the first item i
Andrew Dunstan writes:
> For anything more fine-grained, I'm inclined to say that people need to roll
> their own. pg_restore's --list and --use-list give you extremely
> fine-grained control. I have working scripts which use these for example to
> filter out londiste and pgq objects, certain larg
On 08/26/2011 04:46 PM, Jim Nasby wrote:
On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
I knew there would be some bike-shedding about how we specify these things,
which is why I haven't written docs yet.
While we're debating what shade of yellow to paint the shed...
My actual use case
Alvaro Herrera writes:
> The "--section=data --section=indexes" proposal seems very reasonable to
> me -- more so than "--sections='data indexes'".
+1 ... not only easier to code and less squishily defined, but more like
the existing precedent for other pg_dump switches, such as --table.
On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
> I knew there would be some bike-shedding about how we specify these things,
> which is why I haven't written docs yet.
While we're debating what shade of yellow to paint the shed...
My actual use case is to be able to be able to "inject" SQL
Excerpts from Robert Haas's message of vie ago 26 15:36:36 -0300 2011:
> On Fri, Aug 26, 2011 at 1:15 PM, Andrew Dunstan wrote:
> > I don't have anything in principle against your '--sections="foo bar"'
> > suggestion, but it would be more work to program. Simpler, and probably more
> > consistent
On Fri, Aug 26, 2011 at 1:15 PM, Andrew Dunstan wrote:
> I don't have anything in principle against your '--sections="foo bar"'
> suggestion, but it would be more work to program. Simpler, and probably more
> consistent with how we do other things, would be allowing multiple --section
> options, i
On 08/26/2011 12:46 PM, Robert Haas wrote:
On Fri, Aug 26, 2011 at 11:22 AM, Andrew Dunstan wrote:
But we could also add these switches to pg_dump too if people feel it's
worthwhile. I haven't looked but the logic should not be terribly hard.
Something like the attached, in fact, which seems
On Fri, 2011-08-26 at 12:46 -0400, Robert Haas wrote:
> --sections='predata data'
> --sections='postdata'
> --sections='index'
Agreed. After command line options reach a certain level of complexity,
I think it's worth looking for a more general way to express them.
Regards,
Jeff Davis
-
On Fri, Aug 26, 2011 at 11:22 AM, Andrew Dunstan wrote:
>> But we could also add these switches to pg_dump too if people feel it's
>> worthwhile. I haven't looked but the logic should not be terribly hard.
>
> Something like the attached, in fact, which seems pretty simple.
It seems like there ar
On 08/25/2011 06:15 PM, Andrew Dunstan wrote:
But we could also add these switches to pg_dump too if people feel
it's worthwhile. I haven't looked but the logic should not be terribly
hard.
Something like the attached, in fact, which seems pretty simple.
cheers
andrew
diff --git a
On 08/25/2011 06:05 PM, Jim Nasby wrote:
On Aug 24, 2011, at 7:43 PM, Josh Berkus wrote:
On 8/23/11 1:30 PM, Andrew Dunstan wrote:
Attached is an undocumented patch that allows pg_restore to omit
post-data items or omit all but post-data items. This has been discussed
before, and Simon sent i
On Aug 24, 2011, at 7:43 PM, Josh Berkus wrote:
> On 8/23/11 1:30 PM, Andrew Dunstan wrote:
>>
>> Attached is an undocumented patch that allows pg_restore to omit
>> post-data items or omit all but post-data items. This has been discussed
>> before, and Simon sent in a patch back on 2008, which ha
On 08/24/2011 08:43 PM, Josh Berkus wrote:
On 8/23/11 1:30 PM, Andrew Dunstan wrote:
Attached is an undocumented patch that allows pg_restore to omit
post-data items or omit all but post-data items. This has been discussed
before, and Simon sent in a patch back on 2008, which has bitrotted
som
On 8/23/11 1:30 PM, Andrew Dunstan wrote:
>
> Attached is an undocumented patch that allows pg_restore to omit
> post-data items or omit all but post-data items. This has been discussed
> before, and Simon sent in a patch back on 2008, which has bitrotted
> some. I'm not sure why it was dropped at
37 matches
Mail list logo
