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(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 1 Dec 2015 19:48, "Tom Lane" <tgl@sss.pgh.pa.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@mit.edu> writes:
On 1 Dec 2015 19:48, "Tom Lane" <tgl@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 2, 2015 at 01:16:09AM +0000, Greg Stark wrote:
On 1 Dec 2015 19:48, "Tom Lane" <tgl@sss.pgh.pa.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@momjian.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 +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Dec 2, 2015 at 01:16:09AM +0000, Greg Stark wrote:
On 1 Dec 2015 19:48, "Tom Lane" <tgl@sss.pgh.pa.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--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 4, 2016 at 3:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
On Fri, Jan 1, 2016 at 6:41 AM, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 4, 2016 at 6:24 AM, Michael Paquier
<michael.paquier@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark <stark@mit.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 4, 2016 at 6:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
VAX (simh):
https://docs.google.com/presentation/d/1PG-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/viewFuzzer:
https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/viewVery 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 4, 2016 at 01:18:02PM -0500, Tom Lane wrote:
Greg Stark <stark@mit.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/viewFuzzer:
https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/viewVery 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@momjian.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 +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers