From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
Cc: | Gilles Darold <gilles(at)migops(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Case expression pushdown |
Date: | 2021-07-30 14:17:39 |
Message-ID: | 1000762.1627654659@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> writes:
> The only thing I'm confused about is in T_CaseTestExpr case - how can it
> be that CaseTestExpr collation doesn't match case_arg_cxt->collation ?
> Do we we need to inspect only case_arg_cxt->state? Can we assert that
> collation == case_arg_cxt->collation?
Perhaps, but:
(1) I'm disinclined to make this code look different from the otherwise-
identical coding elsewhere in foreign_expr_walker.
(2) That would create a hard assumption that foreign_expr_walker's
conclusions about the collation of a subexpression match those of
assign_query_collations. I'm not quite sure I believe that (and if
it's true, why aren't we just relying on exprCollation?). Anyway,
if we're to have an assertion that it's true, it should be in some
place that's a lot less out-of-the-way than CaseTestExpr, because
if the assumption gets violated it might be a long time till we
notice.
So I think we're best off to just write it the way I did, at least
so far as this patch is concerned. If we want to rethink the way
collation gets calculated here, that would be material for a
separate patch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-07-30 14:51:10 | Re: Use generation context to speed up tuplesorts |
Previous Message | Robert Haas | 2021-07-30 14:16:44 | Re: Background writer and checkpointer in crash recovery |