Re: pgsql: Further tweaking of print_aligned_vertical().

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Further tweaking of print_aligned_vertical().
Дата
Msg-id 17804.1449024436@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Further tweaking of print_aligned_vertical().  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
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
resultsets, 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.