On tor, 2009-12-10 at 22:02 -0500, Robert Haas wrote:
> On Thu, Dec 10, 2009 at 8:11 PM, Bruce Momjian wrote:
> > One idea would be to change the column _separator_ for newlines --- that
> > way, they don't show up for single-column output.
>
> Hilariously enough, that's exactly what we used to d
Robert Haas writes:
> Hilariously enough, that's exactly what we used to do. I am leaning
> toward the view that we should revert all the ASCII output format
> changes vs. 8.4 and let people use the new unicode mode if they want
> all the spiffy bells and whistles.
There are clearly use-cases fo
On Thu, Dec 10, 2009 at 8:11 PM, Bruce Momjian wrote:
> Andrew Dunstan wrote:
>>
>>
>> Tom Lane wrote:
>> > regression=# select
>> > E'xxx\nxx\n'
>> > as a, 1 as b;
>> > a
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > regression=# select
> > E'xxx\nxx\n'
> > as a, 1 as b;
> > a | b
> > --
Tom Lane wrote:
Andrew Dunstan writes:
If we really want to make linefeeds visible, I think we should place the
indicators immediately after the character preceding the line feed, not
next to the column separator.
Then it's hard to tell it apart from an instance of that character i
Andrew Dunstan writes:
> If we really want to make linefeeds visible, I think we should place the
> indicators immediately after the character preceding the line feed, not
> next to the column separator.
Then it's hard to tell it apart from an instance of that character in
the data.
Tom Lane wrote:
regression=# select
E'xxx\nxx\n'
as a, 1 as b;
a | b
--+---
xxx
Ron Mayer wrote:
> Tom Lane wrote:
>> Why don't you
>> just do "\pset format unaligned" (or "\a" if you're lazy)?
>
> That's fair. Now that I see it, I guess I should have been
> doing that for copy&paste work anyway.
That'll cover my use cases.
-Kevin
--
Sent via pgsql-hackers mailing li
Tom Lane wrote:
> Why don't you
> just do "\pset format unaligned" (or "\a" if you're lazy)?
That's fair. Now that I see it, I guess I should have been
doing that for copy&paste work anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Andrew Dunstan writes:
> Tom Lane wrote:
>> So you can tell a newline in the data from a wrap due to line length.
>> The need to be able to do that is not dependent on how many columns
>> there are.
> If that's really what we want then I think we're doing a terrible job of
> it. Have a look at t
Tom Lane wrote:
Andrew Dunstan writes:
I don't see much virtue of having these characters when there is only
one column.
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
there are.
If that
On Thu, Dec 10, 2009 at 12:43 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> Yeah, I'm thinking we should probably suppress output of format.nl_right
>>> (no matter what the format) where there is only one column. (This is even
>>> uglier with unicode linestyl
Andrew Dunstan writes:
> I don't see much virtue of having these characters when there is only
> one column.
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
there are.
> And clearly I'm not the only person
Tom Lane wrote:
Andrew Dunstan writes:
Yeah, I'm thinking we should probably suppress output of format.nl_right
(no matter what the format) where there is only one column. (This is
even uglier with unicode linestyle, btw). That's a sane rule and it's
not an ugly hack.
Yes it is.
Andrew Dunstan writes:
> Yeah, I'm thinking we should probably suppress output of format.nl_right
> (no matter what the format) where there is only one column. (This is
> even uglier with unicode linestyle, btw). That's a sane rule and it's
> not an ugly hack.
Yes it is. The real problem here
Robert Haas wrote:
> Andrew Dunstan wrote:
>> A simple if ugly hack would make psql use old-ascii print style
>> (which doesn't use these contionuation chars) if the first
>> attribute in the resultset was named 'QUERY PLAN'
> I don't believe that machine-readable EXPLAIN output is the only
>
On Thu, Dec 10, 2009 at 11:44 AM, Ron Mayer
wrote:
> Alvaro Herrera wrote:
>> Robert Haas escribió:
>>> On first blush, I'm inclined to suggest that the addition of + signs
>>> to mark continuation lines is a misfeature.
>>
>> EXPLAIN is a special case. IMHO it should be dealt with accordingly.
>
Ron Mayer wrote:
Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
Is it?
Wouldn't it affec
Alvaro Herrera wrote:
> Robert Haas escribió:
>> On first blush, I'm inclined to suggest that the addition of + signs
>> to mark continuation lines is a misfeature.
>
> EXPLAIN is a special case. IMHO it should be dealt with accordingly.
>
Is it?
Wouldn't it affect anyone who stuck XML in a tx
Robert Haas wrote:
I don't believe that machine-readable EXPLAIN output is the only
multi-line output value that anyone would ever wish to cut and paste
into an editor without picking up a lot of stray garbage, so I don't
think this is a solution.
Well, yes, another example that has just
On Wed, Dec 9, 2009 at 6:41 PM, Andrew Dunstan wrote:
>> Oh, dear. I think that line continuation syntax was recently added -
>> subsequent to the machine-readable EXPLAIN patch. The reason why it's
>> coded to emit everything as a single row is because that will be most
>> convenient for progra
Roger Leigh wrote:
On Thu, Dec 10, 2009 at 10:12:32AM -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
-1
EXPLAIN is a special case. IMHO it should be dealt wi
On Thu, Dec 10, 2009 at 10:12:32AM -0300, Alvaro Herrera wrote:
> Robert Haas escribió:
>
> > On first blush, I'm inclined to suggest that the addition of + signs
> > to mark continuation lines is a misfeature.
>
> -1
>
> EXPLAIN is a special case. IMHO it should be dealt with accordingly.
If
Robert Haas escribió:
> On first blush, I'm inclined to suggest that the addition of + signs
> to mark continuation lines is a misfeature.
-1
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Pos
2009/12/9 Robert Haas :
> On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan wrote:
>>
>> I have just noticed while checking the EXPLAIN YAML patch that the non-text
>> explain formats are output as a single line with embedded line feeds, while
>> the text format is delivered as a set of text records,
Robert Haas wrote:
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan wrote:
I have just noticed while checking the EXPLAIN YAML patch that the non-text
explain formats are output as a single line with embedded line feeds, while
the text format is delivered as a set of text records, one per li
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan wrote:
>
> I have just noticed while checking the EXPLAIN YAML patch that the non-text
> explain formats are output as a single line with embedded line feeds, while
> the text format is delivered as a set of text records, one per line. The
> practical
I have just noticed while checking the EXPLAIN YAML patch that the
non-text explain formats are output as a single line with embedded line
feeds, while the text format is delivered as a set of text records, one
per line. The practical effect of this is that psql decorates the
non-text format
28 matches
Mail list logo
