Remove duplicate line
In 231b7d670b21, while copy-pasting some code into
ExecEvalJsonCoercionFinish(), I (amitlan) accidentally introduced
a duplicate line. Remove it.
Reported-by: Jian He
Discussion:
https://postgr.es/m/CACJufxHcf=bpmrajcjgfjoufv76mwknyz1x3erxswl26eaf...@mail.gmail.com
Branc
Remove duplicate line
In 231b7d670b21, while copy-pasting some code into
ExecEvalJsonCoercionFinish(), I (amitlan) accidentally introduced
a duplicate line. Remove it.
Reported-by: Jian He
Discussion:
https://postgr.es/m/CACJufxHcf=bpmrajcjgfjoufv76mwknyz1x3erxswl26eaf...@mail.gmail.com
Branc
Remove duplicate line
In 231b7d670b21, while copy-pasting some code into
ExecEvalJsonCoercionFinish(), I (amitlan) accidentally introduced
a duplicate line. Remove it.
Reported-by: Jian He
Discussion:
https://postgr.es/m/CACJufxHcf=bpmrajcjgfjoufv76mwknyz1x3erxswl26eaf...@mail.gmail.com
Branc
Fix typos in comments
Commit 19d8e2308bc added enum values with the prefix TU_, but a few
comments still referred to TUUI_, which was used in development
versions of the patches committed as 19d8e2308bc.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20250701110216.8ac8a9e4c6f607f1d954f...
Fix typos in comments
Commit 19d8e2308bc added enum values with the prefix TU_, but a few
comments still referred to TUUI_, which was used in development
versions of the patches committed as 19d8e2308bc.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20250701110216.8ac8a9e4c6f607f1d954f...
Fix typos in comments
Commit 19d8e2308bc added enum values with the prefix TU_, but a few
comments still referred to TUUI_, which was used in development
versions of the patches committed as 19d8e2308bc.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20250701110216.8ac8a9e4c6f607f1d954f...
Fix typos in comments
Commit 19d8e2308bc added enum values with the prefix TU_, but a few
comments still referred to TUUI_, which was used in development
versions of the patches committed as 19d8e2308bc.
Author: Yugo Nagata
Discussion:
https://postgr.es/m/20250701110216.8ac8a9e4c6f607f1d954f...
Revert "Don't lock partitions pruned by initial pruning"
As pointed out by Tom Lane, the patch introduced fragile and invasive
design around plan invalidation handling when locking of prunable
partitions was deferred from plancache.c to the executor. In
particular, it violated assumptions about Ca
generate_base_implied_equalities_const().
Author: Ashutosh Bapat
Reviewed-by: Amit Langote
Discussion:
https://postgr.es/m/caexhw5scmxyfrqofe6odmbiw2rnvbemeeca-p4w_cyueiku...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/887160d1beaec607187261ab1a9411040da3d7b5
This design incorporates suggestions by David Rowley, who proposed
both the key canonicalization and the initial sizing approach to
balance memory usage and CPU efficiency.
Author: Ashutosh Bapat
Reviewed-by: Amit Langote
Reviewed-by: David Rowley
Tested-by: Dmitry Dolgov <9erthali...@g
Ensure first ModifyTable rel initialized if all are pruned
Commit cbc127917e introduced tracking of unpruned relids to avoid
processing pruned relations, and changed ExecInitModifyTable() to
initialize only unpruned result relations. As a result, MERGE
statements that prune all target partitions c
Fix copy-paste error in datum_to_jsonb_internal()
Commit 3c152a27b06 mistakenly repeated JSONTYPE_JSON in a condition,
omitting JSONTYPE_CAST. As a result, datum_to_jsonb_internal() failed
to reject inputs that were casts (e.g., from an enum to json as in the
example below) when used as keys in JS
Fix copy-paste error in datum_to_jsonb_internal()
Commit 3c152a27b06 mistakenly repeated JSONTYPE_JSON in a condition,
omitting JSONTYPE_CAST. As a result, datum_to_jsonb_internal() failed
to reject inputs that were casts (e.g., from an enum to json as in the
example below) when used as keys in JS
On Mon, Mar 3, 2025 at 6:33 PM Robins Tharakan wrote:
> On Fri, 7 Feb 2025 at 18:45, Amit Langote wrote:
>>
>> Track unpruned relids to avoid processing pruned relations
>>
>
> Since this change, the SQL in the bug-report #18830 [1] segfaults reliably.
>
> T
Fix bug in cbc127917 to handle nested Append correctly
A non-leaf partition with a subplan that is an Append node was
omitted from PlannedStmt.unprunableRelids because it was mistakenly
included in PlannerGlobal.prunableRelids due to the way
PartitionedRelPruneInfo.leafpart_rti_map[] is constructe
Remove unstable test suite added by 525392d57
The 'cached-plan-inval' test suite, introduced in 525392d57 under
src/test/modules/delay_execution, aimed to verify that cached plan
invalidation triggers replanning after deferred locks are taken.
However, its ExecutorStart_hook-based approach relies
Don't lock partitions pruned by initial pruning
Before executing a cached generic plan, AcquireExecutorLocks() in
plancache.c locks all relations in a plan's range table to ensure the
plan is safe for execution. However, this locks runtime-prunable
relations that will later be pruned during "initi
On Wed, Feb 19, 2025 at 3:33 PM Amit Langote wrote:
> doc: Fix some issues with JSON_TABLE() exampls
>
> 1. Remove an unused PASSING variable.
>
> 2. Adjust formatting of JSON data used in an example to be valid
> under strict mode
>
> Reported-by: Miłosz Chmura
doc: Fix some issues with JSON_TABLE() examples
1. Remove an unused PASSING variable.
2. Adjust formatting of JSON data used in an example to be valid
under strict mode
Reported-by: Miłosz Chmura
Author: Robert Treat
Discussion:
https://postgr.es/m/173859550337.1071.4748984213168572...@
doc: Fix some issues with JSON_TABLE() exampls
1. Remove an unused PASSING variable.
2. Adjust formatting of JSON data used in an example to be valid
under strict mode
Reported-by: Miłosz Chmura
Author: Robert Treat
Discussion:
https://postgr.es/m/173859550337.1071.4748984213168572...@w
Fix an oversight in cbc127917 to handle MERGE correctly
ExecInitModifyTable() forgot to trim MERGE-related lists to exclude
entries for result relations pruned during initial pruning, so fix
that.
While at it, make the function's use of the pruned resultRelations
list, rather than ModifyTable.res
Track unpruned relids to avoid processing pruned relations
This commit introduces changes to track unpruned relations explicitly,
making it possible for top-level plan nodes, such as ModifyTable and
LockRows, to avoid processing partitions pruned during initial
pruning. Scan-level nodes, such as
Add commit 76aa615943 to .git-blame-ignore-revs
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/79e872fedb4d2f73baa0a80ba572480774edc61b
Modified Files
--
.git-blame-ignore-revs | 3 +++
1 file changed, 3 insertions(+)
Fix bad indentation introduced in commit d47cbf474
Per buildfarm member koel
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/76aa615943049c04efd36ab4765c06eda89cdfea
Modified Files
--
src/backend/executor/execPartition.c | 6 +++---
1 file changed, 3 ins
Perform runtime initial pruning outside ExecInitNode()
This commit builds on the prior change that moved PartitionPruneInfos
out of individual plan nodes into a list in PlannedStmt, making it
possible to initialize PartitionPruneStates without traversing the
plan tree and perform runtime initial p
Move PartitionPruneInfo out of plan nodes into PlannedStmt
This moves PartitionPruneInfo from plan nodes to PlannedStmt,
simplifying traversal by centralizing all PartitionPruneInfo
structures in a single list in it, which holds all instances for the
main query and its subqueries. Instead of plan
Refactor ExecScan() to allow inlining of its core logic
This commit refactors ExecScan() by moving its tuple-fetching,
filtering, and projection logic into an inline-able function,
ExecScanExtended(), defined in src/include/executor/execScan.h.
ExecScanExtended() accepts parameters for EvalPlanQua
Add missing word in comment
Discussion:
https://postgr.es/m/CA+HiwqFgdp8=0_gi+du0fpwzbg7qy3kz_c1wj1devzxc4bc...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/bfeeb065ea2c870cf4d9dfcd552d23d72432e692
Modified Files
--
src/include/storag
t that it was broken.
> We didn't have enable_incremental_sort in v12, plus EXPLAIN makes
> different table alias choices than later branches.
Sorry for the blunder, and thank you for taking care of it.
--
Thanks, Amit Langote
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise join when collations don't match
If the collation of any join key column doesn’t match the collation of
the corresponding partition key, partitionwise joins can yield incorrect
results. For example, rows that would match under the join key collation
might be located in diffe
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Disallow partitionwise grouping when collations don't match
If the collation of any grouping column doesn’t match the collation of
the corresponding partition key, partitionwise grouping can yield
incorrect results. For example, rows that would be grouped under the
grouping collation may end up in
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
Remove unnecessary word in a comment
Relations opened by the executor are only closed once in
ExecCloseRangeTableRelations(), so the word "again" in the comment
for ExecGetRangeTableRelation() is misleading and unnecessary.
Discussion:
https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50o
SQL/JSON: Fix some oversights in commit b6e1157e7
The decision in b6e1157e7 to ignore raw_expr when evaluating a
JsonValueExpr was incorrect. While its value is not ultimately
used (since formatted_expr's value is), failing to initialize it
can lead to problems, for instance, when the expression
SQL/JSON: Fix some oversights in commit b6e1157e7
The decision in b6e1157e7 to ignore raw_expr when evaluating a
JsonValueExpr was incorrect. While its value is not ultimately
used (since formatted_expr's value is), failing to initialize it
can lead to problems, for instance, when the expression
SQL/JSON: Fix some oversights in commit b6e1157e7
The decision in b6e1157e7 to ignore raw_expr when evaluating a
JsonValueExpr was incorrect. While its value is not ultimately
used (since formatted_expr's value is), failing to initialize it
can lead to problems, for instance, when the expression
On Wed, Oct 16, 2024 at 8:39 PM Amit Langote wrote:
>
> Fix typo in comment of transformJsonAggConstructor()
>
> An oversight of 3a8a1f3254b.
>
> Reported-by: Tender Wang
> Author: Tender Wang
> Backpatch-through: 16
Sorry, I forgot to put the Discussion link:
ht
Fix typo in comment of transformJsonAggConstructor()
An oversight of 3a8a1f3254b.
Reported-by: Tender Wang
Author: Tender Wang
Backpatch-through: 16
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c259b1578e006b2f808595fac4d8e45c5cce9d73
Modified Files
-
Fix typo in comment of transformJsonAggConstructor()
An oversight of 3a8a1f3254b.
Reported-by: Tender Wang
Author: Tender Wang
Backpatch-through: 16
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/064e04008533b2b8a82b5dbff7da10abd6e41565
Modified Files
--
Fix typo in comment of transformJsonAggConstructor()
An oversight of 3a8a1f3254b.
Reported-by: Tender Wang
Author: Tender Wang
Backpatch-through: 16
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/4a933eefe11208d02552f34c8fb3a2b13caeb286
Modified Files
--
On Thu, Oct 3, 2024 at 7:12 PM Amit Langote wrote:
> On Thu, Oct 3, 2024 at 18:57 Alexander Korotkov wrote:
>>
>> Hi, Amit!
>>
>> On Thu, Oct 3, 2024 at 6:01 AM Amit Langote wrote:
>> > Fix expression list handling in ATExecAttachPartition()
>>
>>
Replace Unicode apostrophe with ASCII apostrophe
In commit babb3993dbe9, I accidentally introduced a Unicode
apostrophe (U+2019). This commit replaces it with the ASCII
apostrophe (U+0027) for consistency.
Reported-by: Alexander Korotkov
Discussion:
https://postgr.es/m/capphfdunwmbjkjftqxjremk6
On Thu, Oct 3, 2024 at 18:57 Alexander Korotkov
wrote:
> Hi, Amit!
>
> On Thu, Oct 3, 2024 at 6:01 AM Amit Langote
> wrote:
> > Fix expression list handling in ATExecAttachPartition()
>
> +* since it’s needed later to construct the constraint expression for
>
Fix expression list handling in ATExecAttachPartition()
This commit addresses two issues related to the manipulation of the
partition constraint expression list in ATExecAttachPartition().
First, the current use of list_concat() to combine the partition's
constraint (retrieved via get_qual_from_p
SQL/JSON: Update example in JSON_QUERY() documentation
Commit e6c45d85dc fixed the behavior of JSON_QUERY() when WITH
CONDITIONAL WRAPPER is used, but the documentation example wasn't
updated to reflect this change. This commit updates the example to
show the correct result.
Per off-list report f
SQL/JSON: Update example in JSON_QUERY() documentation
Commit 2c27346ed684 fixed the behavior of JSON_QUERY() when WITH
CONDITIONAL WRAPPER is used, but the documentation example wasn't
updated to reflect this change. This commit updates the example to
show the correct result.
Per off-list report
multiple SQL/JSON items
in the result.
Reported-by: Peter Eisentraut
Author: Peter Eisentraut
Author: Amit Langote
Reviewed-by: Andrew Dunstan
Discussion:
https://postgr.es/m/8022e067-818b-45d3-8fab-6e0d94d03626%40eisentraut.org
Backpatch-through: 17
Branch
--
master
Details
---
https
multiple SQL/JSON items
in the result.
Reported-by: Peter Eisentraut
Author: Peter Eisentraut
Author: Amit Langote
Reviewed-by: Andrew Dunstan
Discussion:
https://postgr.es/m/8022e067-818b-45d3-8fab-6e0d94d03626%40eisentraut.org
Backpatch-through: 17
Branch
--
REL_17_STABLE
Details
Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/77aebe9a8d3cccd4c54b43be87a38f2bae6
Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/dd8bea88abf4794d99270ced884a8bc1e387255d
Mod
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
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: 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
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
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, th
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
-
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
--
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 nee
Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3a97460970f344660971ee75d7f5a181bf87f633
Mod
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
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 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: 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
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
Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e4e27976a687dd641c1c8251fad3a90a087
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
s TRUE and FALSE
already works like that because the parser creates a cast expression
including the cast function, but the coercion of the actual result
value is not handled by the parser.
Tests by Jian He.
Reported-by: Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://p
ser itself. jsonb-valued
expressions are now always coerced at runtime and boolean
expressions too if the target type is a string type for the
reasons mentioned above.
Tests are taken from a patch that Jian He posted.
Reported-by: Jian He
Author: Jian He
Author: Amit Langote
Discuss
instead of at parse time.
Reported-by: Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Branch
--
REL_17_STABLE
Details
---
https://git.pos
s TRUE and FALSE
already works like that because the parser creates a cast expression
including the cast function, but the coercion of the actual result
value is not handled by the parser.
Tests by Jian He.
Reported-by: Jian He
Author: Jian He
Author: Amit Langote
Discussion:
https://p
SQL/JSON: Improve error-handling of JsonBehavior expressions
Instead of returning a NULL when the JsonBehavior expression value
could not be coerced to the RETURNING type, throw the error message
informing the user that it is the JsonBehavior expression that caused
the error with the actual coerci
SQL/JSON: Respect OMIT QUOTES when RETURNING domains over jsonb
populate_domain() didn't take into account the omit_quotes flag passed
down to json_populate_type() by ExecEvalJsonCoercion() and that led
to incorrect behavior when the RETURNING type is a domain over
jsonb. Fix that by passing the
SQL/JSON: Remove useless code in ExecInitJsonExpr()
The code was for adding an unconditional JUMP to the next step,
which is unnecessary processing.
Reported-by: Jian He
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Bra
SQL/JSON: Fix error-handling of some JsonBehavior expressions
To ensure that the errors of executing a JsonBehavior expression that
is coerced in the parser are caught instead of being thrown directly,
pass ErrorSaveContext to ExecInitExprRec() when initializing it.
Also, add a EEOP_JSONEXPR_COERC
SQL/JSON: Respect OMIT QUOTES when RETURNING domains over jsonb
populate_domain() didn't take into account the omit_quotes flag passed
down to json_populate_type() by ExecEvalJsonCoercion() and that led
to incorrect behavior when the RETURNING type is a domain over
jsonb. Fix that by passing the
SQL/JSON: Remove useless code in ExecInitJsonExpr()
The code was for adding an unconditional JUMP to the next step,
which is unnecessary processing.
Reported-by: Jian He
Discussion:
https://postgr.es/m/cacjufxeo4sujkcytda0_qt9tazqqkpmf1cqhw9kbouejfqq...@mail.gmail.com
Backpatch-through: 17
Bra
SQL/JSON: Fix error-handling of some JsonBehavior expressions
To ensure that the errors of executing a JsonBehavior expression that
is coerced in the parser are caught instead of being thrown directly,
pass ErrorSaveContext to ExecInitExprRec() when initializing it.
Also, add a EEOP_JSONEXPR_COERC
SQL/JSON: Improve error-handling of JsonBehavior expressions
Instead of returning a NULL when the JsonBehavior expression value
could not be coerced to the RETURNING type, throw the error message
informing the user that it is the JsonBehavior expression that caused
the error with the actual coerci
SQL/JSON: Rethink c2d93c3802b
This essentially reverts c2d93c3802b except tests. The problem with
c2d93c3802b was that it only changed the casting behavior for types
with typmod, and had coding issues noted in the post-commit review.
This commit changes coerceJsonFuncExpr() to use assignment-leve
SQL/JSON: Rethink c2d93c3802b
This essentially reverts c2d93c3802b except tests. The problem with
c2d93c3802b was that it only changed the casting behavior for types
with typmod, and had coding issues noted in the post-commit review.
This commit changes coerceJsonFuncExpr() to use assignment-leve
SQL/JSON: Fix a paragraph in JSON_TABLE documentation
Using text inside parantheses is not a
common or good style, so rephrase a sentence to avoid that style.
Also rephrase the text in that paragraph a bit while at it.
Reported-by: Marcos Pegoraro
Author: Jian He
Reviewed-by: Daniel Gustafsson
SQL/JSON: Fix a paragraph in JSON_TABLE documentation
Using text inside parantheses is not a
common or good style, so rephrase a sentence to avoid that style.
Also rephrase the text in that paragraph a bit while at it.
Reported-by: Marcos Pegoraro
Author: Jian He
Reviewed-by: Daniel Gustafsson
1 - 100 of 218 matches
Mail list logo
