delta/postgresql.git/src/test/regress/sql/guc.sql, branch master git.postgresql.org: git/postgresql.git Remove SQL regression tests for GUCs related to NO_SHOW_ALL 2023-02-08T07:56:21+00:00 Michael Paquier michael@paquier.xyz 2023-02-08T07:56:21+00:00 b7e84c65d5b2d694a669ae1db8ab1d6c51ef8596 No GUCs that use NO_SHOW_ALL are reported in pg_show_all_settings(), hence trying to check combinations of flags related to it is pointless. These queries have been introduced by d10e41d, so backpatch down to 15 to keep all the branches consistent. Equivalent checks based on NO_SHOW_ALL could be added in check_GUC_init() when a GUC is initially loaded, but this can be done only on HEAD. Author: Nitin Jadhav Discussion: https://postgr.es/m/CAMm1aWaYe0muu3ABo7iSAgK+OWDS9yNe8GGRYnCyeEpScYKa+g@mail.gmail.com Backpatch-through: 15 
No GUCs that use NO_SHOW_ALL are reported in pg_show_all_settings(),
hence trying to check combinations of flags related to it is pointless.

These queries have been introduced by d10e41d, so backpatch down to 15
to keep all the branches consistent.  Equivalent checks based on
NO_SHOW_ALL could be added in check_GUC_init() when a GUC is initially
loaded, but this can be done only on HEAD.

Author: Nitin Jadhav
Discussion: https://postgr.es/m/CAMm1aWaYe0muu3ABo7iSAgK+OWDS9yNe8GGRYnCyeEpScYKa+g@mail.gmail.com
Backpatch-through: 15
Introduce GUC_NO_RESET flag. 2022-09-27T15:47:12+00:00 Tom Lane tgl@sss.pgh.pa.us 2022-09-27T15:47:12+00:00 385366426511399a91da327c0f04765bbcfd5322 Previously, the transaction-property GUCs such as transaction_isolation could be reset after starting a transaction, because we marked them as GUC_NO_RESET_ALL but still allowed a targeted RESET. That leads to assertion failures or worse, because those properties aren't supposed to change after we've acquired a transaction snapshot. There are some NO_RESET_ALL variables for which RESET is okay, so we can't just redefine the semantics of that flag. Instead introduce a separate GUC_NO_RESET flag. Mark "seed", as well as the transaction property GUCs, as GUC_NO_RESET. We have to disallow GUC_ACTION_SAVE as well as straight RESET, because otherwise a function having a "SET transaction_isolation" clause can still break things: the end-of-function restore action is equivalent to a RESET. No back-patch, as it's conceivable that someone is doing something this patch will forbid (like resetting one of these GUCs at transaction start, or "CREATE FUNCTION ... SET transaction_read_only = 1") and not running into problems with it today. Given how long we've had this issue and not noticed, the side effects in non-assert builds can't be too serious. Per bug #17385 from Andrew Bille. Masahiko Sawada Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org 
Previously, the transaction-property GUCs such as transaction_isolation
could be reset after starting a transaction, because we marked them
as GUC_NO_RESET_ALL but still allowed a targeted RESET.  That leads to
assertion failures or worse, because those properties aren't supposed
to change after we've acquired a transaction snapshot.

There are some NO_RESET_ALL variables for which RESET is okay, so
we can't just redefine the semantics of that flag.  Instead introduce
a separate GUC_NO_RESET flag.  Mark "seed", as well as the transaction
property GUCs, as GUC_NO_RESET.

We have to disallow GUC_ACTION_SAVE as well as straight RESET, because
otherwise a function having a "SET transaction_isolation" clause can
still break things: the end-of-function restore action is equivalent
to a RESET.

No back-patch, as it's conceivable that someone is doing something
this patch will forbid (like resetting one of these GUCs at transaction
start, or "CREATE FUNCTION ... SET transaction_read_only = 1") and not
running into problems with it today.  Given how long we've had this
issue and not noticed, the side effects in non-assert builds can't be
too serious.

Per bug #17385 from Andrew Bille.

Masahiko Sawada

Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org
Disallow setting bogus GUCs within an extension's reserved namespace. 2022-02-21T19:10:43+00:00 Tom Lane tgl@sss.pgh.pa.us 2022-02-21T19:10:15+00:00 88103567cb8fa5be46dc9fac3e3b8774951a2be7 Commit 75d22069e tried to throw a warning for setting a custom GUC whose prefix belongs to a previously-loaded extension, if there is no such GUC defined by the extension. But that caused unstable behavior with parallel workers, because workers don't necessarily load extensions and GUCs in the same order their leader did. To make that work safely, we have to completely disallow the case. We now actually remove any such GUCs at the time of initial extension load, and then throw an error not just a warning if you try to add one later. While this might create a compatibility issue for a few people, the improvement in error-detection capability seems worth it; it's hard to believe that there's any good use-case for choosing such GUC names. This also un-reverts 5609cc01c (Rename EmitWarningsOnPlaceholders() to MarkGUCPrefixReserved()), since that function's old name is now even more of a misnomer. Florin Irion and Tom Lane Discussion: https://postgr.es/m/1902182.1640711215@sss.pgh.pa.us 
Commit 75d22069e tried to throw a warning for setting a custom GUC whose
prefix belongs to a previously-loaded extension, if there is no such GUC
defined by the extension.  But that caused unstable behavior with
parallel workers, because workers don't necessarily load extensions and
GUCs in the same order their leader did.  To make that work safely, we
have to completely disallow the case.  We now actually remove any such
GUCs at the time of initial extension load, and then throw an error not
just a warning if you try to add one later.  While this might create a
compatibility issue for a few people, the improvement in error-detection
capability seems worth it; it's hard to believe that there's any good
use-case for choosing such GUC names.

This also un-reverts 5609cc01c (Rename EmitWarningsOnPlaceholders() to
MarkGUCPrefixReserved()), since that function's old name is now even
more of a misnomer.

Florin Irion and Tom Lane

Discussion: https://postgr.es/m/1902182.1640711215@sss.pgh.pa.us
Introduce pg_settings_get_flags() to find flags associated to a GUC 2022-01-30T23:56:41+00:00 Michael Paquier michael@paquier.xyz 2022-01-30T23:56:41+00:00 d10e41d4238e7dcd23968230939c0c59cbcb41c2 The most meaningful flags are shown, which are the ones useful for the user and for automating and extending the set of tests supported currently by check_guc. This script may actually be removed in the future, but we are not completely sure yet if and how we want to support the remaining sanity checks performed there, that are now integrated in the main regression test suite as of this commit. Thanks also to Peter Eisentraut and Kyotaro Horiguchi for the discussion. Bump catalog version. Author: Justin Pryzby Discussion: https://postgr.es/m/20211129030833.GJ17618@telsasoft.com 
The most meaningful flags are shown, which are the ones useful for the
user and for automating and extending the set of tests supported
currently by check_guc.

This script may actually be removed in the future, but we are not
completely sure yet if and how we want to support the remaining sanity
checks performed there, that are now integrated in the main regression
test suite as of this commit.

Thanks also to Peter Eisentraut and Kyotaro Horiguchi for the
discussion.

Bump catalog version.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20211129030833.GJ17618@telsasoft.com
Revert changes about warnings/errors for placeholders. 2021-12-27T21:01:10+00:00 Tom Lane tgl@sss.pgh.pa.us 2021-12-27T21:01:10+00:00 cab5b9ab2c066ba904f13de2681872dcda31e207 Revert commits 5609cc01c, 2ed8a8cc5, and 75d22069e until we have a less broken idea of how this should work in parallel workers. Per buildfarm. Discussion: https://postgr.es/m/1640909.1640638123@sss.pgh.pa.us 
Revert commits 5609cc01c, 2ed8a8cc5, and 75d22069e until we have
a less broken idea of how this should work in parallel workers.
Per buildfarm.

Discussion: https://postgr.es/m/1640909.1640638123@sss.pgh.pa.us
Rethink handling of settings with a prefix reserved by an extension. 2021-12-27T19:35:50+00:00 Tom Lane tgl@sss.pgh.pa.us 2021-12-27T19:35:50+00:00 2ed8a8cc5b634d33ea07d681c6b02213da07f792 Commit 75d22069e made SET print a warning if you tried to set an unrecognized parameter within namespace previously reserved by an extension. It seems better for that to be an outright error though, for the same reason that we don't let you set unrecognized unqualified parameter names. In any case, the preceding implementation was inefficient and erroneous. Perform the check in a more appropriate spot, and be more careful about prefix-match cases. Discussion: https://postgr.es/m/116024.1640111629@sss.pgh.pa.us 
Commit 75d22069e made SET print a warning if you tried to set an
unrecognized parameter within namespace previously reserved by an
extension.  It seems better for that to be an outright error though,
for the same reason that we don't let you set unrecognized unqualified
parameter names.  In any case, the preceding implementation was
inefficient and erroneous.  Perform the check in a more appropriate
spot, and be more careful about prefix-match cases.

Discussion: https://postgr.es/m/116024.1640111629@sss.pgh.pa.us
Warning on SET of nonexisting setting with a prefix reserved by an extension 2021-12-01T14:08:32+00:00 Peter Eisentraut peter@eisentraut.org 2021-12-01T14:07:29+00:00 75d22069e00d638d08c04e3aba71688f3fb002ed An extension can already de facto reserve a GUC prefix using EmitWarningsOnPlaceholders(). But this was only checked against settings that exist at the time the extension is loaded (or the extension chooses to call this). No diagnostic is given when a SET command later uses a nonexisting setting with a custom prefix. With this change, EmitWarningsOnPlaceholders() saves the prefixes it reserves in a list, and SET checks when it finds a "placeholder" setting whether it belongs to a reserved prefix and issues a warning in that case. Add a regression test that checks the patch using the "plpgsql" registered prefix. Author: Florin Irion <florin.irion@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/CA+HEvJDhWuuTpGTJT9Tgbdzm4QS4EzPAwDBScWK18H2Q=FVJFw@mail.gmail.com 
An extension can already de facto reserve a GUC prefix using
EmitWarningsOnPlaceholders().  But this was only checked against
settings that exist at the time the extension is loaded (or the
extension chooses to call this).  No diagnostic is given when a SET
command later uses a nonexisting setting with a custom prefix.

With this change, EmitWarningsOnPlaceholders() saves the prefixes it
reserves in a list, and SET checks when it finds a "placeholder"
setting whether it belongs to a reserved prefix and issues a warning
in that case.

Add a regression test that checks the patch using the "plpgsql"
registered prefix.

Author: Florin Irion <florin.irion@enterprisedb.com>
Discussion: https://www.postgresql.org/message-id/flat/CA+HEvJDhWuuTpGTJT9Tgbdzm4QS4EzPAwDBScWK18H2Q=FVJFw@mail.gmail.com
Re-allow custom GUC names that have more than two components. 2021-06-02T22:50:23+00:00 Tom Lane tgl@sss.pgh.pa.us 2021-06-02T22:50:15+00:00 2955c2be79b35fa369c83fa3b5f44661cb88afa9 Commit 3db826bd5 disallowed this case, but it turns out that some people are depending on it. Since the core grammar has allowed it since 3dc37cd8d, it seems like this code should fall in line. Per bug #17045 from Robert Sosinski. Discussion: https://postgr.es/m/17045-6a4a9f0d1513f72b@postgresql.org 
Commit 3db826bd5 disallowed this case, but it turns out that some
people are depending on it.  Since the core grammar has allowed
it since 3dc37cd8d, it seems like this code should fall in line.

Per bug #17045 from Robert Sosinski.

Discussion: https://postgr.es/m/17045-6a4a9f0d1513f72b@postgresql.org
Tighten up allowed names for custom GUC parameters. 2021-04-07T15:22:22+00:00 Tom Lane tgl@sss.pgh.pa.us 2021-04-07T15:22:22+00:00 3db826bd55cd1df0dd8c3d811f8e5b936d7ba1e4 Formerly we were pretty lax about what a custom GUC's name could be; so long as it had at least one dot in it, we'd take it. However, corner cases such as dashes or equal signs in the name would cause various bits of functionality to misbehave. Rather than trying to make the world perfectly safe for that, let's just require that custom names look like "identifier.identifier", where "identifier" means something that scan.l would accept without double quotes. Along the way, this patch refactors things slightly in guc.c so that find_option() is responsible for reporting GUC-not-found cases, allowing removal of duplicative code from its callers. Per report from Hubert Depesz Lubaczewski. No back-patch, since the consequences of the problem don't seem to warrant changing behavior in stable branches. Discussion: https://postgr.es/m/951335.1612910077@sss.pgh.pa.us 
Formerly we were pretty lax about what a custom GUC's name could
be; so long as it had at least one dot in it, we'd take it.
However, corner cases such as dashes or equal signs in the name
would cause various bits of functionality to misbehave.  Rather
than trying to make the world perfectly safe for that, let's
just require that custom names look like "identifier.identifier",
where "identifier" means something that scan.l would accept
without double quotes.

Along the way, this patch refactors things slightly in guc.c
so that find_option() is responsible for reporting GUC-not-found
cases, allowing removal of duplicative code from its callers.

Per report from Hubert Depesz Lubaczewski.  No back-patch,
since the consequences of the problem don't seem to warrant
changing behavior in stable branches.

Discussion: https://postgr.es/m/951335.1612910077@sss.pgh.pa.us
Give up on testing guc.c's behavior for "infinity" inputs. 2019-03-11T21:53:09+00:00 Tom Lane tgl@sss.pgh.pa.us 2019-03-11T21:53:09+00:00 d9c5e9629bf511a51328fd083ee452de88d91d9d Further buildfarm testing shows that on the machines that are failing ac75959cd's test case, what we're actually getting from strtod("-infinity") is a syntax error (endptr == value) not ERANGE at all. This test case is not worth carrying two sets of expected output for, so just remove it, and revert commit b212245f9's misguided attempt to work around the platform dependency. Discussion: https://postgr.es/m/E1h33xk-0001Og-Gs@gemulon.postgresql.org 
Further buildfarm testing shows that on the machines that are failing
ac75959cd's test case, what we're actually getting from strtod("-infinity")
is a syntax error (endptr == value) not ERANGE at all.  This test case
is not worth carrying two sets of expected output for, so just remove it,
and revert commit b212245f9's misguided attempt to work around the platform
dependency.

Discussion: https://postgr.es/m/E1h33xk-0001Og-Gs@gemulon.postgresql.org