pgsql: Doc: Fix and tweak documentation for ANALYZE reporting
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5ba40b62318e4d941497333b72d589420a48d82f Modified Files -- doc/src/sgml/monitoring.sgml | 106 ++- 1 file changed, 54 insertions(+), 52 deletions(-)
pgsql: Improve psql's tab completion for filenames.
Improve psql's tab completion for filenames. The Readline library contains a fair amount of knowledge about how to tab-complete filenames, but it turns out that that doesn't work too well unless we follow its expectation that we use its filename quoting hooks to quote and de-quote filenames. We were trying to do such quote handling within complete_from_files(), and that's still what we have to do if we're using libedit, which lacks those hooks. But for Readline, it works a lot better if we tell Readline that single-quote is a quoting character and then provide hooks that know the details of the quoting rules for SQL and psql meta-commands. Hence, resurrect the quoting hook functions that existed in the original version of tab-complete.c (and were disabled by commit f6689a328 because they "didn't work so well yet"), and whack on them until they do seem to work well. Notably, this fixes bug #16059 from Steven Winfield, who pointed out that the previous coding would strip quote marks from filenames in SQL COPY commands, even though they're syntactically necessary there. Now, we not only don't do that, but we'll add a quote mark when you tab-complete, even if you didn't type one. Getting this to work across a range of libedit versions (and, to a lesser extent, libreadline versions) was depressingly difficult. It will be interesting to see whether the new regression test cases pass everywhere in the buildfarm. Some future patch might try to handle quoted SQL identifiers with similar explicit quoting/dequoting logic, but that's for another day. Patch by me, reviewed by Peter Eisentraut. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd69ec66c88633c09bc9a984a7f0930e09c7c96e Modified Files -- config/programs.m4 | 52 ++- configure| 87 +++- configure.in | 2 +- src/bin/psql/stringutils.c | 6 +- src/bin/psql/stringutils.h | 3 +- src/bin/psql/t/010_tab_completion.pl | 74 ++ src/bin/psql/tab-complete.c | 259 +-- src/include/pg_config.h.in | 8 ++ src/tools/msvc/Solution.pm | 2 + 9 files changed, 438 insertions(+), 55 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb12aefaafce4fb9973794db7ba0152068e608c4 Modified Files -- src/backend/utils/adt/formatting.c | 172 - src/test/regress/expected/horology.out | 2 +- 2 files changed, 84 insertions(+), 90 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/600b953d73ca2f253ff177c43f6650187ae81c9e Modified Files -- src/backend/utils/adt/formatting.c | 174 - src/test/regress/expected/horology.out | 2 +- 2 files changed, 85 insertions(+), 91 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be13f227febc386a892c8beedc2eb00938a57d2c Modified Files -- src/backend/utils/adt/formatting.c | 172 - src/test/regress/expected/horology.out | 4 +- 2 files changed, 85 insertions(+), 91 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/212b870d6743814db3df3a9cd80a8eefcd9f7b2f Modified Files -- src/backend/utils/adt/formatting.c | 172 - src/test/regress/expected/horology.out | 2 +- 2 files changed, 84 insertions(+), 90 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9e24575f6f1bdf013fcd343e1163c72d4316888f Modified Files -- src/backend/utils/adt/formatting.c | 174 - src/test/regress/expected/horology.out | 2 +- 2 files changed, 85 insertions(+), 91 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a576f2a8f2e8a07b35b66c15477e510baa462dec Modified Files -- src/backend/utils/adt/formatting.c | 174 - src/test/regress/expected/horology.out | 2 +- 2 files changed, 85 insertions(+), 91 deletions(-)
pgsql: Clean up formatting.c's logic for matching constant strings.
Clean up formatting.c's logic for matching constant strings. seq_search(), which is used to match input substrings to constants such as month and day names, had a lot of bizarre and unnecessary behaviors. It was mostly possible to avert our eyes from that before, but we don't want to duplicate those behaviors in the upcoming patch to allow recognition of non-English month and day names. So it's time to clean this up. In particular: * seq_search scribbled on the input string, which is a pretty dangerous thing to do, especially in the badly underdocumented way it was done here. Fortunately the input string is a temporary copy, but that was being made three subroutine levels away, making it something easy to break accidentally. The behavior is externally visible nonetheless, in the form of odd case-folding in error reports about unrecognized month/day names. The scribbling is evidently being done to save a few calls to pg_tolower, but that's such a cheap function (at least for ASCII data) that it's pretty pointless to worry about. In HEAD I switched it to be pg_ascii_tolower to ensure it is cheap in all cases; but there are corner cases in Turkish where this'd change behavior, so leave it as pg_tolower in the back branches. * seq_search insisted on knowing the case form (all-upper, all-lower, or initcap) of the constant strings, so that it didn't have to case-fold them to perform case-insensitive comparisons. This likewise seems like excessive micro-optimization, given that pg_tolower is certainly very cheap for ASCII data. It seems unsafe to assume that we know the case form that will come out of pg_locale.c for localized month/day names, so it's better just to define the comparison rule as "downcase all strings before comparing". (The choice between downcasing and upcasing is arbitrary so far as English is concerned, but it might not be in other locales, so follow citext's lead here.) * seq_search also had a parameter that'd cause it to report a match after a maximum number of characters, even if the constant string were longer than that. This was not actually used because no caller passed a value small enough to cut off a comparison. Replicating that behavior for localized month/day names seems expensive as well as useless, so let's get rid of that too. * from_char_seq_search used the maximum-length parameter to truncate the input string in error reports about not finding a matching name. This leads to rather confusing reports in many cases. Worse, it is outright dangerous if the input string isn't all-ASCII, because we risk truncating the string in the middle of a multibyte character. That'd lead either to delivering an illegible error message to the client, or to encoding-conversion failures that obscure the actual data problem. Get rid of that in favor of truncating at whitespace if any (a suggestion due to Alvaro Herrera). In addition to fixing these things, I const-ified the input string pointers of DCH_from_char and its subroutines, to make sure there aren't any other scribbling-on-input problems. The risk of generating a badly-encoded error message seems like enough of a bug to justify back-patching, so patch all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4c70098ffa8cf19e79e7b124ccac05dd338c937b Modified Files -- src/backend/utils/adt/formatting.c | 172 - src/test/regress/expected/horology.out | 4 +- 2 files changed, 85 insertions(+), 91 deletions(-)
Re: pgsql: walreceiver uses a temporary replication slot by default
On Tue, Jan 14, 2020 at 8:57 AM Peter Eisentraut wrote: > walreceiver uses a temporary replication slot by default > > If no permanent replication slot is configured using > primary_slot_name, the walreceiver now creates and uses a temporary > replication slot. A new setting wal_receiver_create_temp_slot can be > used to disable this behavior, for example, if the remote instance is > out of replication slots. > > Reviewed-by: Masahiko Sawada > Discussion: > https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com Neither the commit message for this patch nor any of the comments in the patch seem to explain why this is a desirable change. I assume that's probably discussed on the thread that is linked here, but you shouldn't have to dig through the discussion thread to figure out what the benefits of a change like this are. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f309c812ed3106def62e940ca54718c7eeda8694 Modified Files -- src/backend/utils/adt/formatting.c | 6 +--- src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 5 deletions(-)
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7a9fef2990174cc8315eb20372afb1557e5cb01a Modified Files -- src/backend/utils/adt/formatting.c | 6 +--- src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 5 deletions(-)
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0e63d9641bad3f50f91ee8e351051bddabac8d31 Modified Files -- src/backend/utils/adt/formatting.c | 6 +--- src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 5 deletions(-)
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/451f50813b6f2ddda81c1f7d42976dd7ca506bd0 Modified Files -- src/backend/utils/adt/formatting.c | 6 +--- src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 5 deletions(-)
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d6a9548b2fdc402bf818cab3d7a621fb5c3ced58 Modified Files -- src/backend/utils/adt/formatting.c | 6 +--- src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 5 deletions(-)
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8fc33e6cc10fcd801efff4d8ddbc22011fdd6108 Modified Files -- src/backend/utils/adt/formatting.c | 6 +--- src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 5 deletions(-)
pgsql: Fix an oversight in commit 4c70098ff.
Fix an oversight in commit 4c70098ff. I had supposed that the from_char_seq_search() call sites were all passing the constant arrays you'd expect them to pass ... but on looking closer, the one for DY format was passing the days[] array not days_short[]. This accidentally worked because the day abbreviations in English are all the same as the first three letters of the full day names. However, once we took out the "maximum comparison length" logic, it stopped working. As penance for that oversight, add regression test cases covering this, as well as every other switch case in DCH_from_char() that was not reached according to the code coverage report. Also, fold the DCH_RM and DCH_rm cases into one --- now that seq_search is case independent, there's no need to pass different comparison arrays for those cases. Back-patch, as the previous commit was. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9a3a75cb81d3b060b8e76001d04c78ab4ce0dcef Modified Files -- src/backend/utils/adt/formatting.c | 9 + src/test/regress/expected/horology.out | 63 ++ src/test/regress/sql/horology.sql | 19 ++ 3 files changed, 83 insertions(+), 8 deletions(-)
pgsql: Add configure probe for rl_completion_suppress_quote.
Add configure probe for rl_completion_suppress_quote. I had supposed that all versions of Readline that have filename quoting hooks also have the rl_completion_suppress_quote variable. But it seems OpenBSD managed to find a version someplace that does not, so we'll have to expend a separate configure probe for that. (Light testing suggests that this version also lacks the bugs that make it necessary to frob that variable. Hooray!) Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c32704441d47cc1cbb36367a429814511edb6ffd Modified Files -- config/programs.m4 | 20 +++- configure | 39 +++ src/bin/psql/tab-complete.c | 7 --- src/include/pg_config.h.in | 4 src/tools/msvc/Solution.pm | 1 + 5 files changed, 67 insertions(+), 4 deletions(-)
pgsql: Doc: Fix list of storage parameters available for ALTER TABLE
Doc: Fix list of storage parameters available for ALTER TABLE Only the parameter parallel_workers can be used directly with ALTER TABLE. Issue introduced in 6f3a13f, so backpatch down to 10. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6de7bcb76f6593dcd107a6bfed645f2142bf3225 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: Doc: Fix list of storage parameters available for ALTER TABLE
Doc: Fix list of storage parameters available for ALTER TABLE Only the parameter parallel_workers can be used directly with ALTER TABLE. Issue introduced in 6f3a13f, so backpatch down to 10. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c4c76d198e3db48ac390a46eab66bcaf1d734a2c Modified Files -- doc/src/sgml/ref/alter_table.sgml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: Doc: Fix list of storage parameters available for ALTER TABLE
Doc: Fix list of storage parameters available for ALTER TABLE Only the parameter parallel_workers can be used directly with ALTER TABLE. Issue introduced in 6f3a13f, so backpatch down to 10. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9988facaec81733ab8a67c2bd75b5d3e72c1e16 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: Doc: Fix list of storage parameters available for ALTER TABLE
Doc: Fix list of storage parameters available for ALTER TABLE Only the parameter parallel_workers can be used directly with ALTER TABLE. Issue introduced in 6f3a13f, so backpatch down to 10. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9a9cb1bfd6eb6a5526f2a6b21b5865dac46bd8b Modified Files -- doc/src/sgml/ref/alter_table.sgml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
