Re: some more pg_dump refactoring

2020-07-15 Thread Peter Eisentraut
On 2020-07-09 16:14, Peter Eisentraut wrote: On 2020-07-08 06:42, Fabien COELHO wrote: What do you think about this patch to reorganize the existing code from that old commit? I think it is a definite further improvement. Patch applies cleanly, compiles, global & pg_dump tap test ok, looks ok

Re: some more pg_dump refactoring

2020-07-09 Thread Alvaro Herrera
On 2020-Jul-09, Peter Eisentraut wrote: > On 2020-07-08 06:42, Fabien COELHO wrote: > > > What do you think about this patch to reorganize the existing code from > > > that > > > old commit? > > > > I think it is a definite further improvement. > > > > Patch applies cleanly, compiles, global &

Re: some more pg_dump refactoring

2020-07-09 Thread Peter Eisentraut
On 2020-07-08 06:42, Fabien COELHO wrote: What do you think about this patch to reorganize the existing code from that old commit? I think it is a definite further improvement. Patch applies cleanly, compiles, global & pg_dump tap test ok, looks ok to me. Thanks. I have committed that, and

Re: some more pg_dump refactoring

2020-07-07 Thread Fabien COELHO
Hallo Peter, Would it make sense to accumulate in the other direction, older to newer, so that new attributes are added at the end of the select? I think that could make sense, but the current style was introduced by daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Should we revise that? It seems

Re: some more pg_dump refactoring

2020-07-07 Thread Peter Eisentraut
On 2020-06-30 16:56, Fabien COELHO wrote: Would it make sense to accumulate in the other direction, older to newer, so that new attributes are added at the end of the select? I think that could make sense, but the current style was introduced by daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Should

Re: some more pg_dump refactoring

2020-06-30 Thread Fabien COELHO
Hello, You changed the query strings to use "\n" instead of " ". I would not have changed that, because it departs from the style around, and I do not think it improves readability at the C code level. This was the style that was introduced by daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Yep

Re: some more pg_dump refactoring

2020-06-29 Thread Peter Eisentraut
On 2020-06-25 08:58, Fabien COELHO wrote: You changed the query strings to use "\n" instead of " ". I would not have changed that, because it departs from the style around, and I do not think it improves readability at the C code level. This was the style that was introduced by daa9fe8a5264a3f

Re: some more pg_dump refactoring

2020-06-24 Thread Fabien COELHO
Hallo Peter, My 0.02 €: Patch applies cleanly, compiles, make check and pg_dump tap tests ok. The refactoring is a definite improvements. You changed the query strings to use "\n" instead of " ". I would not have changed that, because it departs from the style around, and I do not think it

Re: some more pg_dump refactoring

2020-06-23 Thread Daniel Gustafsson
> On 23 Jun 2020, at 14:57, Peter Eisentraut > wrote: > > Here is a patch to reorganize dumpFunc() and dumpAgg() in pg_dump, similar to > daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Instead of repeating the almost > same large query in each version branch, use one > query and add a few columns

some more pg_dump refactoring

2020-06-23 Thread Peter Eisentraut
Here is a patch to reorganize dumpFunc() and dumpAgg() in pg_dump, similar to daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Instead of repeating the almost same large query in each version branch, use one query and add a few columns to the SELECT list depending on the version. This saves a lot of