| 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: | Whole Thread | Raw Message | 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 |