pgsql: Fix incorrect format specifier for int64

2024-03-06 Thread John Naylor
Fix incorrect format specifier for int64 Follow-up to ee1b30f12, per buildfarm member mamba. Discussion: https://postgr.es/m/CANWCAZYwyRMU%2BOTVOjK%3Dno1hm-W3ZQ5vrSFM1MFAaLtLydvwzA%40mail.gmail.com Branch -- master Details ---

pgsql: Fix redefinition of typedefs

2024-03-06 Thread John Naylor
Fix redefinition of typedefs Per buildfarm members sifaka and longfin, clang with -Wtypedef-redefinition warns of duplicate typedefs unless building with C11. Follow-up to ee1b30f12. Masahiko Sawada Discussion:

Re: pgsql: Add template for adaptive radix tree

2024-03-06 Thread John Naylor
On Thu, Mar 7, 2024 at 1:32 PM Tom Lane wrote: > > John Naylor writes: > > On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: > >> Hm ... do we know that this is not patent-encumbered technology? > >> Commits citing such specific prior art make me nervous. > > > There are several open source

Re: pgsql: Add template for adaptive radix tree

2024-03-06 Thread Tom Lane
John Naylor writes: > On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: >> Hm ... do we know that this is not patent-encumbered technology? >> Commits citing such specific prior art make me nervous. > There are several open source implementations in a variety of > languages, so I assumed not. Are

Re: pgsql: Add template for adaptive radix tree

2024-03-06 Thread John Naylor
On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: > > John Naylor writes: > > This implements a radix tree data structure based on the design in > > "The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases" > > by Viktor Leis, Alfons Kemper, and ThomasNeumann, 2013. > > Hm ... do we know

Re: pgsql: Add template for adaptive radix tree

2024-03-06 Thread Tom Lane
John Naylor writes: > This implements a radix tree data structure based on the design in > "The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases" > by Viktor Leis, Alfons Kemper, and ThomasNeumann, 2013. Hm ... do we know that this is not patent-encumbered technology? Commits

pgsql: Add template for adaptive radix tree

2024-03-06 Thread John Naylor
Add template for adaptive radix tree This implements a radix tree data structure based on the design in "The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases" by Viktor Leis, Alfons Kemper, and ThomasNeumann, 2013. The main technique that makes it adaptive is using several different

pgsql: Revert "Add recovery TAP test for race condition with slot inval

2024-03-06 Thread Michael Paquier
Revert "Add recovery TAP test for race condition with slot invalidations" This reverts commit 08a52ab151ca, due to some sporadic instability in the test. Getting the test right should require some redesign with a second injection point, but let's revert it for now to avoid these issues in the CI

pgsql: Revert "Fix parallel-safety check of expressions and predicate f

2024-03-06 Thread Michael Paquier
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of

pgsql: Revert "Fix parallel-safety check of expressions and predicate f

2024-03-06 Thread Michael Paquier
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of

pgsql: Revert "Fix parallel-safety check of expressions and predicate f

2024-03-06 Thread Michael Paquier
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of

pgsql: Revert "Fix parallel-safety check of expressions and predicate f

2024-03-06 Thread Michael Paquier
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of

pgsql: Revert "Fix parallel-safety check of expressions and predicate f

2024-03-06 Thread Michael Paquier
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of

pgsql: Revert "Fix parallel-safety check of expressions and predicate f

2024-03-06 Thread Michael Paquier
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of

pgsql: Add Unicode property tables.

2024-03-06 Thread Jeff Davis
Add Unicode property tables. Provide functions to test for Unicode properties, such as Alphabetic or Cased. These functions use tables derived from Unicode data files, similar to the tables for Unicode normalization or general category, and those tables can be updated with the 'update-unicode'

pgsql: Fix type-checking of RECORD-returning functions in FROM.

2024-03-06 Thread Tom Lane
Fix type-checking of RECORD-returning functions in FROM. In the corner case where a function returning RECORD has been simplified to a RECORD constant or an inlined ROW() expression, ExecInitFunctionScan failed to cross-check the function's result rowtype against the coldeflist provided by the

pgsql: Fix type-checking of RECORD-returning functions in FROM.

2024-03-06 Thread Tom Lane
Fix type-checking of RECORD-returning functions in FROM. In the corner case where a function returning RECORD has been simplified to a RECORD constant or an inlined ROW() expression, ExecInitFunctionScan failed to cross-check the function's result rowtype against the coldeflist provided by the

pgsql: Fix type-checking of RECORD-returning functions in FROM.

2024-03-06 Thread Tom Lane
Fix type-checking of RECORD-returning functions in FROM. In the corner case where a function returning RECORD has been simplified to a RECORD constant or an inlined ROW() expression, ExecInitFunctionScan failed to cross-check the function's result rowtype against the coldeflist provided by the

pgsql: Fix type-checking of RECORD-returning functions in FROM.

2024-03-06 Thread Tom Lane
Fix type-checking of RECORD-returning functions in FROM. In the corner case where a function returning RECORD has been simplified to a RECORD constant or an inlined ROW() expression, ExecInitFunctionScan failed to cross-check the function's result rowtype against the coldeflist provided by the

pgsql: Fix type-checking of RECORD-returning functions in FROM.

2024-03-06 Thread Tom Lane
Fix type-checking of RECORD-returning functions in FROM. In the corner case where a function returning RECORD has been simplified to a RECORD constant or an inlined ROW() expression, ExecInitFunctionScan failed to cross-check the function's result rowtype against the coldeflist provided by the

pgsql: Fix type-checking of RECORD-returning functions in FROM.

2024-03-06 Thread Tom Lane
Fix type-checking of RECORD-returning functions in FROM. In the corner case where a function returning RECORD has been simplified to a RECORD constant or an inlined ROW() expression, ExecInitFunctionScan failed to cross-check the function's result rowtype against the coldeflist provided by the

pgsql: Fix signedness error in 9f225e992 for gcc

2024-03-06 Thread John Naylor
Fix signedness error in 9f225e992 for gcc The first argument of vshrq_n_s8 needs to be a signed vector type, but it was passed unsigned. Clang is more lax with conversion, but gcc needs a cast. Fix by me, tested by Masahiko Sawada Per buildfarm members splitfin, batta, widowbird, snakefly,

pgsql: Fix parallel-safety check of expressions and predicate for index

2024-03-06 Thread Michael Paquier
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions().

pgsql: Fix parallel-safety check of expressions and predicate for index

2024-03-06 Thread Michael Paquier
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions().

pgsql: Fix parallel-safety check of expressions and predicate for index

2024-03-06 Thread Michael Paquier
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions().

pgsql: Fix parallel-safety check of expressions and predicate for index

2024-03-06 Thread Michael Paquier
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions().

pgsql: Fix parallel-safety check of expressions and predicate for index

2024-03-06 Thread Michael Paquier
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions().

pgsql: Fix parallel-safety check of expressions and predicate for index

2024-03-06 Thread Michael Paquier
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions().