On Thu, Dec 27, 2018 at 10:55:43PM +0100, Fabien COELHO wrote:
> I do not "want" to do a patch for that:-) Anyway, a small patch is attached
> which adds comments to pg_dumpall output sections.
Patch has been moved to next CF with the same status, ready for
committer. Andrew, are you planning to
Hello,
While poking around the dump output, I noticed some unrelated points:
* Command "pg_dump" could tell which database is dumped in the output
Or "pg_dumpall" could issue a comment line in the output telling which
database is being considered.
* The database dumps should have an introduct
On 12/25/18 3:36 AM, Fabien COELHO wrote:
>
> Hello Andrew,
>
>> Rebased and updated patch attached.
>
> Here is a review of v5, sorry for the delay.
>
> Patch applies cleanly, compiles, "make check" is ok.
>
> I do not see Michaël's issue, and do not see how it could be so, for
> me the whole da
On Tue, Dec 25, 2018 at 10:32:34AM +0100, Fabien COELHO wrote:
> Joyeuses fêtes !
Merci. You too Happy New Year and Merry christmas. (Sentence valid
for all folks reading this email, as well as folks not reading it).
--
Michael
signature.asc
Description: PGP signature
Bonjour Michaël,
I do not see Michaël's issue [...]
Sorry for the noise.
No big deal!
-- PostgreSQL database "foo" dump
Or "pg_dumpall" could issue a comment line in the output telling which
database is being considered.
Mentioning which database dump has been completed in the end co
On Tue, Dec 25, 2018 at 09:36:05AM +0100, Fabien COELHO wrote:
> I do not see Michaël's issue, and do not see how it could be so, for me the
> whole database-specific section generated by the underlying "pg_dump" call
> is removed, as expected.
>
> All is well for me, I turned the patch as ready.
Hello Andrew,
Rebased and updated patch attached.
Here is a review of v5, sorry for the delay.
Patch applies cleanly, compiles, "make check" is ok.
I do not see Michaël's issue, and do not see how it could be so, for me
the whole database-specific section generated by the underlying "pg_du
On Mon, Dec 24, 2018 at 02:46:48PM -0500, Andrew Dunstan wrote:
> I think you're mistaken. The following example shows this clearly -
> there is nothing corresponding to the 20 excluded databases. What you're
> referring to appears to be the statements that preceded the 'CREATE
> DATABASE' statemen
On 12/19/18 3:55 PM, Andrew Dunstan wrote:
> On 12/18/18 11:53 PM, Michael Paquier wrote:
>> On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
>>> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
On 11/17/18 9:55 AM, Alvaro Herrera wrote:
> In the long run, I think we should add
On 12/18/18 11:53 PM, Michael Paquier wrote:
> On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
>> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>>> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
In the long run, I think we should add an option to processSQLNamePattern
to use OR
On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
>>> In the long run, I think we should add an option to processSQLNamePattern
>>> to use OR instead of AND, which would fix both this problem as
On 11/18/18 1:41 PM, Andrew Dunstan wrote:
On 11/17/18 9:55 AM, Alvaro Herrera wrote:
The comment in expand_dbname_patterns is ungrammatical and mentions
"OID" rather than "name", so I suggest
/*
* The loop below might sometimes result in duplicate entries in the
* output name l
> On Sun, Nov 18, 2018 at 7:41 PM Andrew Dunstan
> wrote:
>
> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
> > The comment in expand_dbname_patterns is ungrammatical and mentions
> > "OID" rather than "name", so I suggest
>
> Will fix.
>
> > Other than that, the patch seems fine to me -- I tested a
On 11/17/18 9:55 AM, Alvaro Herrera wrote:
The comment in expand_dbname_patterns is ungrammatical and mentions
"OID" rather than "name", so I suggest
/*
* The loop below might sometimes result in duplicate entries in the
* output name list, but we don't care.
The comment in expand_dbname_patterns is ungrammatical and mentions
"OID" rather than "name", so I suggest
/*
* The loop below might sometimes result in duplicate entries in the
* output name list, but we don't care.
*/
I'm not sure this is grammatical either:
On Wed, Oct 31, 2018 at 05:44:26PM +0100, Fabien COELHO wrote:
> Patch v4 applies cleanly, compiles, doc generation ok, global & local tests
> ok.
+# also fails for -r and -t, but it seems pointless to add more tests
for those.
+command_fails_like(
+ [ 'pg_dumpall', '--exclude-database=foo',
:-( My fault, I just created a new one.
Hmmm... so did I:-) We did it a few minutes apart. I did not find yours
when I first searched, then I proceeded to try to move the previous CF
entry which had been marked as "returned" but this was rejected, so I
recreated the one without checking whe
On 10/31/2018 12:44 PM, Fabien COELHO wrote:
Hello Andrew,
This patch addresses all these concerns.
Patch v4 applies cleanly, compiles, doc generation ok, global & local
tests ok.
Tiny comments: there is a useless added blank line at the beginning of
the added varlistenry.
I have re
Hello Andrew,
This patch addresses all these concerns.
Patch v4 applies cleanly, compiles, doc generation ok, global & local
tests ok.
Tiny comments: there is a useless added blank line at the beginning of the
added varlistenry.
I have recreated the CF entry and put the patch to ready.
On 10/13/2018 10:07 AM, Fabien COELHO wrote:
Hello Andrew,
A question: would it makes sense to have a symmetrical
--include-database=PATTERN option as well?
I don't think so. If you only want a few databases, just use pg_dump.
The premise of pg_dumpall is that you want all of them and thi
Hello Andrew,
A question: would it makes sense to have a symmetrical
--include-database=PATTERN option as well?
I don't think so. If you only want a few databases, just use pg_dump. The
premise of pg_dumpall is that you want all of them and this switch provides
for exceptions to that.
Ok
On 08/03/2018 05:08 PM, Fabien COELHO wrote:
Among other use cases, this is useful where a database name is
visible but the database is not dumpable by the user. Examples of
this occur in some managed Postgres services.
This looks like a reasonable feature.
Thanks for the review.
I
On Fri, Aug 03, 2018 at 11:08:57PM +0200, Fabien COELHO wrote:
> Patch applies cleanly, compiles, and works for me.
Last review has not been addressed, so please note that this has been
marked as returned with feedback.
--
Michael
signature.asc
Description: PGP signature
Among other use cases, this is useful where a database name is visible but
the database is not dumpable by the user. Examples of this occur in some
managed Postgres services.
This looks like a reasonable feature.
I will add this to the September CF.
My 0.02€:
Patch applies cleanly, compi
PFA a patch to provide an --exclude-database option for pg_dumpall. The
causes pg_dumpall to skip any database whose name matches the argument
pattern. The option can be used multiple times.
Among other use cases, this is useful where a database name is visible
but the database is not dumpa
25 matches
Mail list logo
