Re: sql/json query function JsonBehavior default expression's collation may differ from returning type's collation

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql/json query function JsonBehavior default expression's collation may differ from returning type's collation
Date: 2025-08-12 11:08:54
Message-ID: CA+HiwqH4J2VLL6jHQ8ei7UMt=FedAYA0bYjJ7+_Khtj_hc_MeQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Jian,

Thanks for the patch and also for the offlist heads-up.

I agree with rejecting cases where the DEFAULT clause’s collation does not
match the RETURNING collation. The result collation for json_value should
come from the RETURNING clause if it has an explicit COLLATE, otherwise
from the RETURNING type’s collation, and both the extracted value source
(the value obtained from the JSON path when it matches) and the DEFAULT
source should match it.

I would not add a T_CollateExpr arm to exprSetCollation(). CollateExpr is
just a transient wrapper that the planner rewrites to RelabelType, so it
does not make sense to stamp it with a result collation there. Instead,
transformJsonBehavior() should check if a source expression is a
CollateExpr, verify that its collOid matches the target collation, and
either keep it as is (no stamping needed if the collOid already matches the
target) or strip the wrapper and stamp the inner node with
exprSetCollation() if you need the inner node itself to carry the target
collation.

That is my current understanding of how exprSetCollation works, but I will
confirm when I can check the code on my computer next week. Someone like
Tom can correct me if I have missed something in the meantime.

Thanks, Amit Langote

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2025-08-12 11:13:51 Re: Excessive LOG messages from replication slot sync worker
Previous Message Japin Li 2025-08-12 11:05:56 Re: Excessive LOG messages from replication slot sync worker