pgsql: Further tweaking of print_aligned_vertical().

Further tweaking of print_aligned_vertical().

Don't force the data width to extend all the way to the right margin if it
doesn't need to. This reverts the behavior in non-wrapping cases to be
what it was in 9.4. Also, make the logic that ensures the data line width
is at least equal to the record-header line width a little less obscure.

In passing, avoid possible calculation of log10(0). Probably that's
harmless, given the lack of field complaints, but it seems risky:
conversion of NaN to an integer isn't well defined.

Branch
------
REL9_5_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/181346cf9892820c94f51525d2c38684148812bf

Modified Files
--------------
src/bin/psql/print.c | 56 ++++++++++++++++++++++--------------
src/test/regress/expected/psql.out | 40 +++++++++++++-------------
2 files changed, 55 insertions(+), 41 deletions(-)

On 1 Dec 2015 19:48, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> In passing, avoid possible calculation of log10(0). Probably that's
> harmless, given the lack of field complaints, but it seems risky:
> conversion of NaN to an integer isn't well defined.

Am I going to have to fire up the emulator again?

Greg Stark <stark(at)mit(dot)edu> writes:
> On 1 Dec 2015 19:48, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> In passing, avoid possible calculation of log10(0). Probably that's
>> harmless, given the lack of field complaints, but it seems risky:
>> conversion of NaN to an integer isn't well defined.

> Am I going to have to fire up the emulator again?

No, 'cause I fixed it ;-). I initially thought that the case might
be unreachable, but it isn't: you can get there with cont->nrows == 0
if you have FETCH_SIZE set and the resultset size is an exact multiple
of FETCH_SIZE.

While poking at that, though, I ran into yet another bug in this code:

regression=# \pset format wrapped
Output format is wrapped.
regression=# \x
Expanded display is on.
regression=# select repeat('xyzzy',22) from generate_series(1,25);
-[ RECORD 1 ]------------------------------------------------------------------
repeat | xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy.
|.xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy
-[ RECORD 2 ]------------------------------------------------------------------
repeat | xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy.
|.xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy
.. etc etc ...

regression=# \set FETCH_COUNT 2
regression=# select repeat('xyzzy',22) from generate_series(1,25);
-[ RECORD 1 ]-------------------------------------------------------------------
---------------------------------------
repeat | xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyx
yzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy
-[ RECORD 2 ]-------------------------------------------------------------------
---------------------------------------
repeat | xyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyx
yzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzyxyzzy
.. etc etc ...

That is, wrap width determination is broken the moment you set FETCH_SIZE.

The reason seems to be this ugly kluge in ExecQueryUsingCursor():

else if (pset.queryFout == stdout && !did_pager)
{
/*
* If query requires multiple result sets, hack to ensure that
* only one pager instance is used for the whole mess
*/
pset.queryFout = PageOutput(100000, &(my_popt.topt));
did_pager = true;
}

After we have run that code, pset.queryFout is no longer pointing at
stdout, which breaks every single one of the "fout == stdout" tests in
print.c. It'd be all right if those tests knew that they were dealing
with an is_pager situation, but they don't because that critical piece of
information is not passed down to printQuery(). I think we could probably
fix this by making is_pager an additional argument of printQuery() and its
relevant subroutines.

regards, tom lane

On Wed, Dec 2, 2015 at 01:16:09AM +0000, Greg Stark wrote:
>
> On 1 Dec 2015 19:48, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > In passing, avoid possible calculation of log10(0).  Probably that's
> > harmless, given the lack of field complaints, but it seems risky:
> > conversion of NaN to an integer isn't well defined.
>
> Am I going to have to fire up the emulator again?

Greg's lightning talk in Vienna about how he got the emulator working
was priceless. I know he posted the VAX results, but how he got them
was amazing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +

On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, Dec 2, 2015 at 01:16:09AM +0000, Greg Stark wrote:
>>
>> On 1 Dec 2015 19:48, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >
>> > In passing, avoid possible calculation of log10(0). Probably that's
>> > harmless, given the lack of field complaints, but it seems risky:
>> > conversion of NaN to an integer isn't well defined.
>>
>> Am I going to have to fire up the emulator again?
>
> Greg's lightning talk in Vienna about how he got the emulator working
> was priceless. I know he posted the VAX results, but how he got them
> was amazing.

+1. The work of a pure hacker.
--
Michael

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Greg's lightning talk in Vienna about how he got the emulator working
>> was priceless. I know he posted the VAX results, but how he got them
>> was amazing.

> +1. The work of a pure hacker.

Is this available online anywhere?

regards, tom lane

On Mon, Jan 4, 2016 at 3:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> Greg's lightning talk in Vienna about how he got the emulator working
>>> was priceless. I know he posted the VAX results, but how he got them
>>> was amazing.
>
>> +1. The work of a pure hacker.
>
> Is this available online anywhere?

Arg, actually it is not:
https://wiki.postgresql.org/wiki/PostgreSQL_Conference_Europe_Talks_2015
Greg could you add it there?
--
Michael

On Mon, Jan 4, 2016 at 6:24 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> Arg, actually it is not:
> https://wiki.postgresql.org/wiki/PostgreSQL_Conference_Europe_Talks_2015
> Greg could you add it there?

No, apparently that page is restricted to only some users.

I used plenty of images I pulled off the net without regard for
copyright so I hesitated to put it up. I suppose that's par for the
course with these kinds of presentations. In any case it was just a
quick lightning talk I threw together to describe a few days of mostly
waiting around for builds to finish. Here are the two lightning talks
on Google:

VAX (simh):
https://docs.google.com/presentation/d/1PG-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/view

Fuzzer:
https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/view

--
greg

Greg Stark <stark(at)mit(dot)edu> writes:
> I used plenty of images I pulled off the net without regard for
> copyright so I hesitated to put it up. I suppose that's par for the
> course with these kinds of presentations. In any case it was just a
> quick lightning talk I threw together to describe a few days of mostly
> waiting around for builds to finish. Here are the two lightning talks
> on Google:

> VAX (simh):
> https://docs.google.com/presentation/d/1PG-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/view

> Fuzzer:
> https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/view

Very cool, thanks!

regards, tom lane

On Mon, Jan 4, 2016 at 6:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> VAX (simh):
>> https://docs.google.com/presentation/d/1PG-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/view
>
>> Fuzzer:
>> https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/view
>
> Very cool, thanks!

Incidentally, I did boot up the simulator again the other day because
I had had an idea for how we might get the regression tests to pass.
However the idea didn't pan out. I thought maybe we could compile just
float.c with -msoft-float so that the backend used VAX floats and the
user datatype was represented by IEEE floats. I'm sure there are a few
places where we assume we can convert one to the other but I was
hoping it would be few enough to be manageable to fix up. I wasn't
sure how feasible it was to have a mixed build at all and I was going
to experiment.

However gcc doesn't support -msoft-float on VAX. Apparently
-msoft-float is an implemented by the architecture backend rather than
as a portable general purpose feature :(

--
greg

On Mon, Jan 4, 2016 at 01:18:02PM -0500, Tom Lane wrote:
> Greg Stark <stark(at)mit(dot)edu> writes:
> > I used plenty of images I pulled off the net without regard for
> > copyright so I hesitated to put it up. I suppose that's par for the
> > course with these kinds of presentations. In any case it was just a
> > quick lightning talk I threw together to describe a few days of mostly
> > waiting around for builds to finish. Here are the two lightning talks
> > on Google:
>
> > VAX (simh):
> > https://docs.google.com/presentation/d/1PG-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/view
>
> > Fuzzer:
> > https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/view
>
> Very cool, thanks!

No, you need to see the video! It was amazing. I couldn't believe what
I was hearing. I was like "YOU DID WHAT!" Unfortunately, I don't think
it was recorded. :-(

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +