Обсуждение: Re: [PATCH] Resolve iso-8859-1-type literals in GRAPH_TABLE COLUMNS
Hi SATYANARAYANA, On Sun, Apr 26, 2026 at 3:53 AM SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote: > > Hi hackers, > > transformRangeGraphTable() calls transformExpr() and > assign_list_collations() for COLUMNS expressions but missed calling > resolveTargetListUnknowns(). As a result, literals such as 'val1' > in a COLUMNS clause retained type "unknown", causing failures with > ORDER BY, UNION, and output conversions. > > Fix by calling resolveTargetListUnknowns() on the columns target > list right after assign_list_collations(), similar to SELECT target lists in > transformSelectStmt(). > > Attached a patch to fix this, which also includes test cases to reproduce. I can reproduce this and the patch fixes it. One question: why is resolveTargetListUnknowns called after assign_list_collations? I'm asking because in transformSelectStmt, resolveTargetListUnknowns is invoked before assign_query_collations. It might not matter, but keeping the order consistent would be good for readers. > > > Thanks, > Satya > > -- Regards Junwang Zhao
Re: [PATCH] Resolve iso-8859-1-type literals in GRAPH_TABLE COLUMNS
От
SATYANARAYANA NARLAPURAM
Дата:
Hi,
On Sun, Apr 26, 2026 at 8:10 AM Junwang Zhao <zhjwpku@gmail.com> wrote:
Hi SATYANARAYANA,
On Sun, Apr 26, 2026 at 3:53 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> Hi hackers,
>
> transformRangeGraphTable() calls transformExpr() and
> assign_list_collations() for COLUMNS expressions but missed calling
> resolveTargetListUnknowns(). As a result, literals such as 'val1'
> in a COLUMNS clause retained type "unknown", causing failures with
> ORDER BY, UNION, and output conversions.
>
> Fix by calling resolveTargetListUnknowns() on the columns target
> list right after assign_list_collations(), similar to SELECT target lists in
> transformSelectStmt().
>
> Attached a patch to fix this, which also includes test cases to reproduce.
I can reproduce this and the patch fixes it.
One question: why is resolveTargetListUnknowns called after
assign_list_collations?
I'm asking because in transformSelectStmt, resolveTargetListUnknowns
is invoked before assign_query_collations. It might not matter, but keeping
the order consistent would be good for readers.
Updated the patch. It should be before.
Thanks,
Satya
Вложения
On 29.04.26 16:09, Ashutosh Bapat wrote: > On Mon, Apr 27, 2026 at 11:34 AM SATYANARAYANA NARLAPURAM > <satyanarlapuram@gmail.com> wrote: >> >> Hi, >> >> On Sun, Apr 26, 2026 at 8:10 AM Junwang Zhao <zhjwpku@gmail.com> wrote: >>> >>> Hi SATYANARAYANA, >>> >>> On Sun, Apr 26, 2026 at 3:53 AM SATYANARAYANA NARLAPURAM >>> <satyanarlapuram@gmail.com> wrote: >>>> >>>> Hi hackers, >>>> >>>> transformRangeGraphTable() calls transformExpr() and >>>> assign_list_collations() for COLUMNS expressions but missed calling >>>> resolveTargetListUnknowns(). As a result, literals such as 'val1' >>>> in a COLUMNS clause retained type "unknown", causing failures with >>>> ORDER BY, UNION, and output conversions. >>>> >>>> Fix by calling resolveTargetListUnknowns() on the columns target >>>> list right after assign_list_collations(), similar to SELECT target lists in >>>> transformSelectStmt(). >>>> >>>> Attached a patch to fix this, which also includes test cases to reproduce. >>> >>> I can reproduce this and the patch fixes it. >>> >>> One question: why is resolveTargetListUnknowns called after >>> assign_list_collations? >>> >>> I'm asking because in transformSelectStmt, resolveTargetListUnknowns >>> is invoked before assign_query_collations. It might not matter, but keeping >>> the order consistent would be good for readers. >> >> >> Updated the patch. It should be before. > > Do we really need a test for ORDER BY on a literal column? I replaced > all the test queries with a single one which covers all the scenarios > covered by those queries. > > The patch needed to consider pstate->p_resolve_unknowns. Unknown > literals are not resolved as text always. See the test query. I couldn't find a commit to apply this patch cleanly (the subject says patch 5/5, so maybe you had some unpublished local changes?). After applying the test case manually, it looks like the test output is already correct without the code change. So if this patch is still required, we need a better test case.