Add callback for backend initialization in pgstats
pgstat_initialize() is currently used by the WAL stats as a code path to
take some custom actions when a backend starts. A callback is added to
generalize the concept so as all stats kinds can do the same, for
builtin and custom kinds, if set.
R
Fix misleading error message context
Author: Pavel Stehule
Reviewed-by: Stepan Neretin
Discussion:
https://www.postgresql.org/message-id/flat/CAFj8pRAw+OkVW=FgMKHKyvY3CgtWy3cWdY7XT+S5TJaTttu=o...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4af1
Fix handling of NULL return value in typarray lookup
Commit 6ebeeae29 accidentally omitted testing the return value from
findTypeByOid which can return NULL. Fix by adding a check to make
sure that we have a pointer to dereference.
Author: Ranier Vilela
Reviewed-by: Nathan Bossart
Reviewed-by:
Prevent mis-encoding of "trailing junk after numeric literal" errors.
Since commit 2549f0661, we reject an identifier immediately following
a numeric literal (without separating whitespace), because that risks
ambiguity with hex/octal/binary integers. However, that patch used
token patterns like
Prevent mis-encoding of "trailing junk after numeric literal" errors.
Since commit 2549f0661, we reject an identifier immediately following
a numeric literal (without separating whitespace), because that risks
ambiguity with hex/octal/binary integers. However, that patch used
token patterns like
Prevent mis-encoding of "trailing junk after numeric literal" errors.
Since commit 2549f0661, we reject an identifier immediately following
a numeric literal (without separating whitespace), because that risks
ambiguity with hex/octal/binary integers. However, that patch used
token patterns like
Prevent mis-encoding of "trailing junk after numeric literal" errors.
Since commit 2549f0661, we reject an identifier immediately following
a numeric literal (without separating whitespace), because that risks
ambiguity with hex/octal/binary integers. However, that patch used
token patterns like
Be more careful with error paths in pg_set_regex_collation().
Set global variables after error paths so that they don't end up in an
inconsistent state.
The inconsistent state doesn't lead to an actual problem, because
after an error, pg_set_regex_collation() will be called again before
the globa
doc PG 17 relnotes: remove tab complete for MERGE/SPLIT partit.
commit 60ae37a8b
Backpatch-through: 17 only
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/35afec71aeb3723df57a6c3da1f98014b51d22e0
Modified Files
--
doc/src/sgml/release-17.sgml
SQL/JSON: Fix JSON_TABLE() column deparsing
The deparsing code in get_json_expr_options() unnecessarily emitted
the default column-specific ON ERROR / EMPTY behavior when the
top-level ON ERROR behavior in JSON_TABLE was set to ERROR. Fix that
by not overriding the column-specific default, determi
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
When the ON ERROR / ON EMPTY behavior is to return NULL, returning
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
no need to create separate steps to check the error/empty flag or
those to evaluate the the c
Update comment about ExprState.escontext
The updated comment provides more helpful guidance by mentioning that
escontext should be set when soft error handling is needed.
Reported-by: Jian He
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Back
SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE
Use EMPTY ARRAY instead of EMPTY.
This change does not affect the runtime behavior of JSON_TABLE(),
which continues to return an empty relation ON ERROR. It only alters
whether the default ON ERROR behavior is shown in the deparsed output.
R
SQL/JSON: Fix JSON_TABLE() column deparsing
The deparsing code in get_json_expr_options() unnecessarily emitted
the default column-specific ON ERROR / EMPTY behavior when the
top-level ON ERROR behavior in JSON_TABLE was set to ERROR. Fix that
by not overriding the column-specific default, determi
Update comment about ExprState.escontext
The updated comment provides more helpful guidance by mentioning that
escontext should be set when soft error handling is needed.
Reported-by: Jian He
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Back
SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE
Use EMPTY ARRAY instead of EMPTY.
This change does not affect the runtime behavior of JSON_TABLE(),
which continues to return an empty relation ON ERROR. It only alters
whether the default ON ERROR behavior is shown in the deparsed output.
R
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
When the ON ERROR / ON EMPTY behavior is to return NULL, returning
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
no need to create separate steps to check the error/empty flag or
those to evaluate the the c
On Fri, Sep 6, 2024 at 12:07 PM Amit Langote wrote:
> SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
>
> When the ON ERROR / ON EMPTY behavior is to return NULL, returning
> NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
> no need to create separate step
Revert recent SQL/JSON related commits
Reverts c88ce386c4d, 5067c230b8e, and e4e27976a68, because a few BF
animals didn't like one or all of them.
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/eef5195f300bb9cf2864d48761c0db2ad93842c1
Modified Files
--
Revert recent SQL/JSON related commits
Reverts 68222851d5a8, 565caaa79af, and 3a97460970f, because a few
BF animals didn't like one or all of them.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4d7e24e0f4d05b546228488ccdc2848a80245ffb
Modified Files
-
Amit Langote writes:
> This or one of the other of my recent commits have broken some BF
> animals, so reverting for now.
Unfiltered EXPLAIN VERBOSE output in a regression test is a
guaranteed fail.
regards, tom lane
On Fri, Sep 6, 2024 at 1:09 PM Tom Lane wrote:
> Amit Langote writes:
> > This or one of the other of my recent commits have broken some BF
> > animals, so reverting for now.
>
> Unfiltered EXPLAIN VERBOSE output in a regression test is a
> guaranteed fail.
Yes, thanks for the note. Will change
Amit Langote writes:
> Yes, thanks for the note. Will change the test case to test what are
> deparsing related changes in some other manner.
I usually prefer to test ruleutils.c by deparsing a suitable view.
regards, tom lane
On Fri, Sep 6, 2024 at 1:19 PM Tom Lane wrote:
> Amit Langote writes:
> > Yes, thanks for the note. Will change the test case to test what are
> > deparsing related changes in some other manner.
>
> I usually prefer to test ruleutils.c by deparsing a suitable view.
Yeah, other tests in that fil
24 matches
Mail list logo
