On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja pgm...@joh.to writes:
Here's the third version of this patch, hopefully this time without any
problems. I looked through the patch and it looked OK, but I did that
last time too so I wouldn't trust myself on
On 4/29/14 4:29 PM, Keith Fiske wrote:
Was this ever committed into core? Apologies, I'm not very familiar with
looking through the commit history of the source code and I don't see
anything about this option or pretty-print outputs in the pg_dump/restore
docs for 9.3. Had someone asking me
Keith Fiske ke...@omniti.com writes:
On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Applied with corrections.
Was this ever committed into core? Apologies, I'm not very familiar with
looking through the commit history of the source code and I don't see
anything about this
On Tue, Apr 29, 2014 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Keith Fiske ke...@omniti.com writes:
On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Applied with corrections.
Was this ever committed into core? Apologies, I'm not very familiar with
looking through
Huh, I had assumed this was old behaviour. I didn't realize this was
new with 9.3.
Considering the thread pg_get_viewdefs() indentation considered
harmful I'm beginning to think this was a regression. It results in
some dump files being unnecessarily large and the pg_dump consuming
too much
Greg Stark st...@mit.edu writes:
Huh, I had assumed this was old behaviour. I didn't realize this was
new with 9.3.
Considering the thread pg_get_viewdefs() indentation considered
harmful I'm beginning to think this was a regression. It results in
some dump files being unnecessarily large
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Here's a draft patch tackling point 1. This gets rid of a whole lot
of parenthesization, as well as indentation, for simple UNION lists.
You can see the results in the changed regression test outputs.
[...]
Comments?
+1.
Thanks,
On Wed, Apr 30, 2014 at 6:33 AM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Here's a draft patch tackling point 1. This gets rid of a whole lot
of parenthesization, as well as indentation, for simple UNION lists.
You can see the results in the changed
On 2/3/13 10:06 PM, Tom Lane wrote:
Applied with corrections.
Thank you.
The xml expected output was still wrong - to do that part right, you
need to update xml.out with an xml-enabled build and xml_1.out with a
non-xml-enabled build.
Ahh. That explains a lot.
Regards,
Marko Tiikkaja
Marko Tiikkaja pgm...@joh.to writes:
Here's the third version of this patch, hopefully this time without any
problems. I looked through the patch and it looked OK, but I did that
last time too so I wouldn't trust myself on that one.
Applied with corrections.
The xml expected output was
On Thu, Jan 31, 2013 at 4:40 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Andrew Dunstan and...@dunslane.net writes:
Well, we could actually set the wrap value to 0, which would mean always
wrap. That wouldn't be making any assumption about the user's terminal
window size ;-)
+1
Andrew Dunstan and...@dunslane.net writes:
Well, we could actually set the wrap value to 0, which would mean always
wrap. That wouldn't be making any assumption about the user's terminal
window size ;-)
+1
Personally I find the wrapped case MUCH more readable. I guess anything is
an
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
Looks good this time.
Will mark Ready for committor
Thanks for reviewing it more carefully than I did! :-) And my apologies
for the confusion earlier.
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put that by default but other people may object so I
will keep that in code committors plate.
I have no opinion on this
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put that by default but other people may object so I
will keep that in code
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we should put that by default but other people
On 01/30/2013 11:03 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
On 1/30/13 7:52 AM, Jeevan Chalke wrote:
However, I am not sure about putting WRAP_COLUMN_DEFAULT by default. In
my opinion we
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2013 11:03 AM, Tom Lane wrote:
FWIW, I'd vote for not enabling that by default --- it's basically an
unwarranted assumption about how wide people's terminal windows are.
Well, we could actually set the wrap value to 0, which would mean
Hi Marko,
On Mon, Jan 28, 2013 at 5:01 PM, Marko Tiikkaja pgm...@joh.to wrote:
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff
On 1/29/13 10:18 AM, Jeevan Chalke wrote:
That's fine. I am not at all pointing that to you. Have a look at this:
Ugh.. I'm sorry, I don't understand how this happened. I manually
looked through all the changes, but somehow this slipped through. Will
have a look this evening.
Regards,
Hi Marko,
On Wed, Jan 30, 2013 at 2:07 AM, Marko Tiikkaja pgm...@joh.to wrote:
On Tue, 29 Jan 2013 10:18:51 +0100, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com wrote:
That's fine. I am not at all pointing that to you. Have a look at this:
Here's the
Hi Marko,
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
However, will you please justify the changes done in xml.out ? I guess
they are not needed.
You might need to configure your sources with libxml.
Also, I am not sure about putting
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff |filterdiff --format=context to re-format the patches to the
context diff preferred on
On 28/01/13 12:31, Marko Tiikkaja wrote:
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff |filterdiff --format=context to re-format the
On Thu, Jan 10, 2013 at 11:07 PM, Andrew Dunstan and...@dunslane.netwrote:
On 01/10/2013 12:35 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think there's a very good case for breaking the nexus between
PRETTYFLAG_PAREN and PRETTYFLAG_INDENT+line wrapping for views. Only
On Thu, Jan 10, 2013 at 01:23:10PM +0100, Marko Tiikkaja wrote:
Hi,
At the company I work for, we've been splitting dumps into separate
files and diffing them for a while now. By far the biggest problem
we had was with views: pg_dump by default dumps views on one line,
in a format which
* David Fetter (da...@fetter.org) wrote:
On Thu, Jan 10, 2013 at 01:23:10PM +0100, Marko Tiikkaja wrote:
Any feedback is welcome.
Why not make this the new default? That way, new users will have the
benefit, and people with tools or processes that depend on the old
behavior can still have
On 01/10/2013 07:23 AM, Marko Tiikkaja wrote:
Hi,
At the company I work for, we've been splitting dumps into separate
files and diffing them for a while now. By far the biggest problem we
had was with views: pg_dump by default dumps views on one line, in a
format which maximizes
On 1/10/13 3:22 PM, Andrew Dunstan wrote:
For versions = 9.2 it would be better to allow passing in a
pretty-print value, like 80 or 0, instead of just passing 'true'. The
new line-wrapping that the integer argument triggers is much more
readable than the supposedly pretty value that 'true'
Marko Tiikkaja pgm...@joh.to writes:
While we can do the actual splitting of objects from a -Fc dump
relatively easily, we can't fix the view definitions after they've been
dumped. So I'm proposing a --pretty-print-views setting to pg_dump
(patch attached).
-1. The reason that pg_dump
On Thu, Jan 10, 2013 at 11:21:13AM -0500, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
While we can do the actual splitting of objects from a -Fc dump
relatively easily, we can't fix the view definitions after they've
been dumped. So I'm proposing a --pretty-print-views setting to
David Fetter da...@fetter.org writes:
On Thu, Jan 10, 2013 at 11:21:13AM -0500, Tom Lane wrote:
-1. The reason that pg_dump does not pretty-print things is that
it's unsafe; there is no real guarantee that the view will reload as
intended, because it's under-parenthesized. (Even if we were
On 01/10/2013 12:09 PM, Tom Lane wrote:
Now, we could consider changing the safe mode so that it tries to
provide nice whitespace/line breaks while not risking removal of
parentheses. But that would be a totally different patch, and I'm
not sure how much it would address Marko's desires
Andrew Dunstan and...@dunslane.net writes:
I think there's a very good case for breaking the nexus between
PRETTYFLAG_PAREN and PRETTYFLAG_INDENT+line wrapping for views. Only
PRETTYFLAG_PAREN affects the safety issue. The others are just about
white space in safe places.
What I was
On 01/10/2013 12:35 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think there's a very good case for breaking the nexus between
PRETTYFLAG_PAREN and PRETTYFLAG_INDENT+line wrapping for views. Only
PRETTYFLAG_PAREN affects the safety issue. The others are just about
white
35 matches
Mail list logo
