pgsql: Prevent generating EEOP_AGG_STRICT_INPUT_CHECK operations when n
Prevent generating EEOP_AGG_STRICT_INPUT_CHECK operations when nargs == 0. This only became a problem with 4c640f4f38, which didn't synchronize the value agg_strict_input_check.nargs is set to, with the guard condition for emitting the operation. Besides such instructions being unnecessary overhead, currently the LLVM JIT provider doesn't support them. It seems more sensible to avoid generating such instruction than supporting them. Add assertions to make it easier to debug a potential further occurance. Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108a...@email.cz Backpatch: 11-, like 4c640f4f38. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/793beab37e8f7ec6a4ef39395c6c866d7e4c7af5 Modified Files -- src/backend/executor/execExpr.c | 2 +- src/backend/jit/llvm/llvmjit_expr.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-)
pgsql: Fix STRICT check for strict aggregates with NULL ORDER BY column
Fix STRICT check for strict aggregates with NULL ORDER BY columns. I (Andres) broke this unintentionally in 69c3936a14, by checking strictness for all input expressions computed for an aggregate, rather than just the input for the aggregate transition function. Reported-By: Ondřej Bouda Bisected-By: Tom Lane Diagnosed-By: Andrew Gierth Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108a...@email.cz Backpatch: 11-, like 69c3936a14 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4c640f4f38d5d68cbe33ddfabbdc56eea8f1e173 Modified Files -- src/backend/executor/execExpr.c | 2 +- src/test/regress/expected/aggregates.out | 15 +++ src/test/regress/sql/aggregates.sql | 7 +++ 3 files changed, 23 insertions(+), 1 deletion(-)
pgsql: Fix STRICT check for strict aggregates with NULL ORDER BY column
Fix STRICT check for strict aggregates with NULL ORDER BY columns. I (Andres) broke this unintentionally in 69c3936a14, by checking strictness for all input expressions computed for an aggregate, rather than just the input for the aggregate transition function. Reported-By: Ondřej Bouda Bisected-By: Tom Lane Diagnosed-By: Andrew Gierth Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108a...@email.cz Backpatch: 11-, like 69c3936a14 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fd59b29c873915064f7af6a33c968c97e0d59166 Modified Files -- src/backend/executor/execExpr.c | 2 +- src/test/regress/expected/aggregates.out | 15 +++ src/test/regress/sql/aggregates.sql | 7 +++ 3 files changed, 23 insertions(+), 1 deletion(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/73dbaed93b460f9ac1cf9b13d591f2cdc4d06aa1 Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf4a9562e8b93ebb69715c7dbdfc90dd6945e369 Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0ae902e39ed8e20abce8b6db2daec7f2abbadb5b Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33c697e9d4a0ace1429ae88ae584935d9d6faada Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f7ba6e951a12fb1d8cc3cd1346e02856009f9c4c Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/981dc2baa8e08483bfe4b20f9e5ab3cad711ba98 Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Make ts_locale.c's character-type functions cope with UTF-16.
Make ts_locale.c's character-type functions cope with UTF-16. On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+ will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f...@postgresql.org Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6e6092989fbb27fecdbfbcd66f39e10f18aa0a69 Modified Files -- src/backend/tsearch/ts_locale.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-)
pgsql: Fix tablespace handling for partitioned indexes
Fix tablespace handling for partitioned indexes When creating partitioned indexes, the tablespace was not being saved for the parent index. This meant that subsequently created partitions would not use the right tablespace for their indexes. ALTER INDEX SET TABLESPACE and ALTER INDEX ALL IN TABLESPACE raised errors when tried; fix them too. This requires bespoke code for ATExecCmd() that applies to the special case when the tablespace move is just a catalog change. Discussion: https://postgr.es/m/20181102003138.uxpaca6qfxzskepi@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dfa6081419829ef60d6bc02691616337eeb7f988 Modified Files -- src/backend/catalog/heap.c| 10 +- src/backend/commands/tablecmds.c | 60 +-- src/test/regress/input/tablespace.source | 10 ++ src/test/regress/output/tablespace.source | 19 +- 4 files changed, 94 insertions(+), 5 deletions(-)
pgsql: Fix tablespace handling for partitioned indexes
Fix tablespace handling for partitioned indexes When creating partitioned indexes, the tablespace was not being saved for the parent index. This meant that subsequently created partitions would not use the right tablespace for their indexes. ALTER INDEX SET TABLESPACE and ALTER INDEX ALL IN TABLESPACE raised errors when tried; fix them too. This requires bespoke code for ATExecCmd() that applies to the special case when the tablespace move is just a catalog change. Discussion: https://postgr.es/m/20181102003138.uxpaca6qfxzskepi@alvherre.pgsql Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33e6c34c32677a168bee4bc6c335aa8d73211a56 Modified Files -- src/backend/catalog/heap.c| 10 +- src/backend/commands/tablecmds.c | 60 +-- src/test/regress/input/tablespace.source | 10 ++ src/test/regress/output/tablespace.source | 19 +- 4 files changed, 94 insertions(+), 5 deletions(-)
pgsql: Remove extra word from create sub docs
Remove extra word from create sub docs Improve the documentation in the CREATE SUBSCRIPTION command a bit by removing an extraneous word and spelling out 'information'. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cf2245159172836db29d8f0bc7d7164fd33714b1 Modified Files -- doc/src/sgml/ref/create_subscription.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
