pgsql: Fix compiler warning in multirange_constructor0()

2020-12-21 Thread Alexander Korotkov
Fix compiler warning in multirange_constructor0() Discussion: https://postgr.es/m/X%2BBP8XE0UpIB6Yvh%40paquier.xyz Author: Michael Paquier Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/29f8f546767ebb4253f6dc37815e2d95fff9acd0 Modified Files -- src/bac

Re: pgsql: Multirange datatypes

2020-12-21 Thread Alexander Korotkov
Hi, Michael! On Mon, Dec 21, 2020 at 10:34 AM Michael Paquier wrote: > On Sun, Dec 20, 2020 at 04:21:16AM +, Alexander Korotkov wrote: > > Multirange datatypes > > > > Multiranges are basically sorted arrays of non-overlapping ranges with > > set-theoretic operations defined over them. > > Th

Re: pgsql: Multirange datatypes

2020-12-21 Thread Alexander Korotkov
On Sun, Dec 20, 2020 at 11:02 PM Alexander Korotkov wrote: > On Sun, Dec 20, 2020 at 5:56 PM Alexander Korotkov > wrote: > > On Sun, Dec 20, 2020 at 4:37 PM Alexander Korotkov > > wrote: > > > On Sun, Dec 20, 2020 at 8:16 AM Alexander Korotkov > > > wrote: > > > There also appears to be some

pgsql: Consider unsorted paths in generate_useful_gather_paths

2020-12-21 Thread Tomas Vondra
Consider unsorted paths in generate_useful_gather_paths generate_useful_gather_paths used to skip unsorted paths (without any pathkeys), but that is unnecessary - the later code actually can handle such paths just fine by adding a Sort node. This is clearly a thinko, preventing construction of use

pgsql: Consider unsorted paths in generate_useful_gather_paths

2020-12-21 Thread Tomas Vondra
Consider unsorted paths in generate_useful_gather_paths generate_useful_gather_paths used to skip unsorted paths (without any pathkeys), but that is unnecessary - the later code actually can handle such paths just fine by adding a Sort node. This is clearly a thinko, preventing construction of use

pgsql: Check parallel safety in generate_useful_gather_paths

2020-12-21 Thread Tomas Vondra
Check parallel safety in generate_useful_gather_paths Commit ebb7ae839d ensured we ignore pathkeys with volatile expressions when considering adding a sort below a Gather Merge. Turns out we need to care about parallel safety of the pathkeys too, otherwise we might try sorting e.g. on results of a

pgsql: Check parallel safety in generate_useful_gather_paths

2020-12-21 Thread Tomas Vondra
Check parallel safety in generate_useful_gather_paths Commit ebb7ae839d ensured we ignore pathkeys with volatile expressions when considering adding a sort below a Gather Merge. Turns out we need to care about parallel safety of the pathkeys too, otherwise we might try sorting e.g. on results of a

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Remove "invalid concatenation of jsonb objects" error case.

2020-12-21 Thread Tom Lane
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let'

pgsql: Disallow SRFs when considering sorts below Gather Merge

2020-12-21 Thread Tomas Vondra
Disallow SRFs when considering sorts below Gather Merge While we do allow SRFs in ORDER BY, scan/join processing should not consider such cases - such sorts should only happen via final Sort atop a ProjectSet. So make sure we don't try adding such sorts below Gather Merge, just like we do for expr

pgsql: Disallow SRFs when considering sorts below Gather Merge

2020-12-21 Thread Tomas Vondra
Disallow SRFs when considering sorts below Gather Merge While we do allow SRFs in ORDER BY, scan/join processing should not consider such cases - such sorts should only happen via final Sort atop a ProjectSet. So make sure we don't try adding such sorts below Gather Merge, just like we do for expr

pgsql: Don't search for volatile expr in find_em_expr_usable_for_sortin

2020-12-21 Thread Tomas Vondra
Don't search for volatile expr in find_em_expr_usable_for_sorting_rel While prepare_sort_from_pathkeys has to be concerned about matching up a volatile expression to the proper tlist entry, we don't need to do that in find_em_expr_usable_for_sorting_rel becausee such a sort will have to be postpon

pgsql: Don't search for volatile expr in find_em_expr_usable_for_sortin

2020-12-21 Thread Tomas Vondra
Don't search for volatile expr in find_em_expr_usable_for_sorting_rel While prepare_sort_from_pathkeys has to be concerned about matching up a volatile expression to the proper tlist entry, we don't need to do that in find_em_expr_usable_for_sorting_rel becausee such a sort will have to be postpon

pgsql: Improve find_em_expr_usable_for_sorting_rel comment

2020-12-21 Thread Tomas Vondra
Improve find_em_expr_usable_for_sorting_rel comment Clarify the relationship between find_em_expr_usable_for_sorting_rel and prepare_sort_from_pathkeys, i.e. what restrictions need to be shared between those two places. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discuss

pgsql: Improve find_em_expr_usable_for_sorting_rel comment

2020-12-21 Thread Tomas Vondra
Improve find_em_expr_usable_for_sorting_rel comment Clarify the relationship between find_em_expr_usable_for_sorting_rel and prepare_sort_from_pathkeys, i.e. what restrictions need to be shared between those two places. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discuss

Re: pgsql: Multirange datatypes

2020-12-21 Thread Michael Paquier
On Mon, Dec 21, 2020 at 02:31:44PM +0300, Alexander Korotkov wrote: > Thank you for catching this! Pushed. Thanks for the commit, Alexander. -- Michael signature.asc Description: PGP signature