Re: BUG #16623: JSON select query result is getting differed when we change DB version

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16623: JSON select query result is getting differed when we change DB version
Дата
Msg-id 445213.1600437166@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #16623: JSON select query result is getting differed when we change DB version  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> Could you please give your inputs on below issue that how we can proceed
> further. We are moving our application which is currently using Postgres10.4
> into Postgres9.6.2.

Why would you be interested in going to an older major version?
If for some reason you absolutely had to, why in the world would
you choose a minor version that is seventeen releases out of date?
Go read the release notes for the 9.6.x series, and ask yourself
if you don't want any of the post-9.6.2 bug fixes.

> Issue: When we read JSON array element values, Postgres10.4 is giving proper
> response based on array elements index but Postgres9.6.2 is returning the
> results like 'CROSS JOIN' outputs even retrieved from single column.

It looks to me like the issue here is the multiple, nested set-returning
functions.  In v10 we rewrote the way those work and fixed some weird
behaviors that were left over from the original Berkeley implementation.
See

https://www.postgresql.org/docs/10/xfunc-sql.html#XFUNC-SQL-FUNCTIONS-RETURNING-SET

particularly the NOTE that says

    Before PostgreSQL 10, putting more than one set-returning function in
    the same select list did not behave very sensibly unless they always
    produced equal numbers of rows. Otherwise, what you got was a number
    of output rows equal to the least common multiple of the numbers of
    rows produced by the set-returning functions. Also, nested
    set-returning functions did not work as described above; instead, a
    set-returning function could have at most one set-returning argument,
    and each nest of set-returning functions was run independently. Also,
    conditional execution (set-returning functions inside CASE etc) was
    previously allowed, complicating things even more. Use of the LATERAL
    syntax is recommended when writing queries that need to work in older
    PostgreSQL versions, because that will give consistent results across
    different versions.

So yeah, 9.6.x is buggy here, but it won't be fixed.  If you really
need to make the query work the same in both versions, use the LATERAL
equivalent explained in the v10 documentation.

            regards, tom lane



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: BUG #16622: pg_dump produces erroneus ALTER TABLE statement for a table with an inherited generated column
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16624: Query Optimizer - Performance bug related to predicate simplification