On Wed, Apr 30, 2014 at 6:33 AM, Stephen Frost 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 regression test o
* 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,
Greg Stark 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 and the p
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 memo
On Tue, Apr 29, 2014 at 11:14 AM, Tom Lane wrote:
> Keith Fiske writes:
> > On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane 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
Keith Fiske writes:
> On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane 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 option or pretty-print outpu
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 about
On Sun, Feb 3, 2013 at 4:06 PM, Tom Lane wrote:
> "Marko Tiikkaja" 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
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" 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 still wron
On Thu, Jan 31, 2013 at 4:40 PM, Dimitri Fontaine wrote:
> Andrew Dunstan 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
>
+1
After looking at both the SQL
Andrew Dunstan 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 advance, but turning o
Andrew Dunstan 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 always
> wrap.
On 01/30/2013 11:03 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja 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 othe
Andrew Dunstan writes:
> On 01/30/2013 09:58 AM, Tom Lane wrote:
>> Marko Tiikkaja 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
>>>
On 01/30/2013 09:58 AM, Tom Lane wrote:
Marko Tiikkaja 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.
Marko Tiikkaja 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 to on
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
Hi Marko,
On Wed, Jan 30, 2013 at 2:07 AM, Marko Tiikkaja wrote:
> On Tue, 29 Jan 2013 10:18:51 +0100, Jeevan Chalke <
> jeevan.chalke@enterprisedb.**com > wrote:
>
>> That's fine. I am not at all pointing that to you. Have a look at this:
>>
>
> Here's the third version of this patch, hopefull
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 Mon, Jan 28, 2013 at 5:01 PM, 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 |filte
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 p
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
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 "WRAP_COLUMN_DEFA
On Thu, Jan 10, 2013 at 11:07 PM, Andrew Dunstan wrote:
>
> On 01/10/2013 12:35 PM, Tom Lane wrote:
>
>> Andrew Dunstan 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 affe
On 01/10/2013 12:35 PM, Tom Lane wrote:
Andrew Dunstan 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.
Andrew Dunstan 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 actually thinking abou
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 any
David Fetter 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 sure
>> it
On Thu, Jan 10, 2013 at 11:21:13AM -0500, Tom Lane wrote:
> Marko Tiikkaja 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_
Marko Tiikkaja 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 does not pre
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' prov
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 compatibili
* 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 stil
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 whi
35 matches
Mail list logo
