Re: [Bug Fix]ECPG: cancellation of significant digits on ECPG

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [Bug Fix]ECPG: cancellation of significant digits on ECPG
Дата
Msg-id CA+q6zcVK7DgOpoKe0zTJ3WC7v+9_fakceN9gRKqhX=TQb5uZVw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [Bug Fix]ECPG: cancellation of significant digits on ECPG  ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
Ответы RE: [Bug Fix]ECPG: cancellation of significant digits on ECPG  ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
Список pgsql-hackers
> On Tue, 6 Nov 2018 at 10:19, Higuchi, Daisuke <higuchi.daisuke@jp.fujitsu.com> wrote:
>
> Thank you for checking!
> I rebased patches on the current master, so I attach them.

After adding 'EXEC SQL ALLOCATE DESCRIPTOR sqlda' I've managed to reproduce the
problem you're talking about, and indeed it looks strange:

=# table testtab ;
   c1
---------
1.23456
0.12345
0.01234
(3 rows)

but in ecpg program we've got from gdb:

# for the second record 0.12345
$$1 = {
  ndigits = 5,
  weight = -1,
  rscale = 5,
  dscale = 5,
  sign = 0,
  buf = 0x5555557636d8 "",
  digits = 0x5555557636da "\001\002\003\004"
}

# for the third record 0.01234
$$0 = {
  ndigits = 4,
  weight = -2,
  rscale = 5,
  dscale = 5,
  sign = 0,
  buf = 0x555555763578 "",
  digits = 0x55555576357b "\001\002"
}

Also what's strange for me is that after applying your patches I still got the
same output, not sure why:

    ./numeric_test
    ndigits :6
    buf     :0   1   2   3   4   5   6
    digits  :1   2   3   4   5   6
    numeric :1.23456
    ----------------------------
    ndigits :5
    buf     :0   0   1   2   3   4   0
    digits  :1   2   3   4   0
    numeric :0.12340
    ----------------------------
    ndigits :4
    buf     :0   0   0   1   2   0   0
    digits  :1   2   0   0
    numeric :0.01200
    ----------------------------


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

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: csv format for psql
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Optimizing nested ConvertRowtypeExpr execution