Per Alvaro's advice, forking this from [1].
In that thread, Tom had asked if it wouldn't be better to find a new
place to put extraUpdatedCols [2] instead of RangeTblEntry, along with
the permission-checking fields are now no longer stored in
RangeTblEntry.
In [3] of the same thread, I proposed t
On Thu, 8 Dec 2022 at 08:17, Amit Langote wrote:
>
> On Wed, Dec 7, 2022 at 8:54 PM Amit Langote wrote:
> > Per Alvaro's advice, forking this from [1].
> >
> > In that thread, Tom had asked if it wouldn't be better to find a new
> > place to put extraUpdatedCols [2] instead of RangeTblEntry, alon
Amit Langote writes:
> Updated to replace a list_nth() with list_nth_node() and rewrote the
> commit message.
So I was working through this with intent to commit, when I realized
that the existing code it's revising is flat out broken. You can't
simply translate a parent rel's set of dependent g
I wrote:
> I think what we have to do basically is repeat what fill_extraUpdatedCols
> does independently for each target table. That's not really horrible:
> given the premise that we're moving this calculation into the planner,
> we can have expand_single_inheritance_child run the code while we
I wrote:
> After further thought: maybe we should get radical and postpone this
> work all the way to executor startup. The downside of that is having
> to do it over again on each execution of a prepared plan. But the
> upside is that when the UPDATE targets a many-partitioned table,
> we would
On Thu, Jan 5, 2023 at 4:59 AM Tom Lane wrote:
> I wrote:
> > After further thought: maybe we should get radical and postpone this
> > work all the way to executor startup. The downside of that is having
> > to do it over again on each execution of a prepared plan. But the
> > upside is that whe
Amit Langote writes:
> On Thu, Jan 5, 2023 at 4:59 AM Tom Lane wrote:
>> Here's a draft patch that does it like that. This seems like a win
>> for more reasons than just pruning, because I was able to integrate
>> the calculation into runtime setup of the expressions, so that we
>> aren't doing
On Fri, Jan 6, 2023 at 12:28 AM Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 5, 2023 at 4:59 AM Tom Lane wrote:
> >> I've not looked into what it'd take to back-patch this. We can't
> >> add a field to ResultRelInfo in released branches (cf 4b3e37993),
> >> but we might be able to rep
Amit Langote writes:
> BTW, you wrote in the commit message:
> (At present it seems that we don't enforce that for partitioning
> either, which is likely wrong to some degree or other; but the case
> clearly needs to be handled with traditional inheritance.)
> Maybe I'm missing someth
On Fri, Jan 6, 2023 at 3:33 PM Tom Lane wrote:
> Amit Langote writes:
> > BTW, you wrote in the commit message:
> > (At present it seems that we don't enforce that for partitioning
> > either, which is likely wrong to some degree or other; but the case
> > clearly needs to be handled
On Wed, Dec 7, 2022 at 8:54 PM Amit Langote wrote:
> Per Alvaro's advice, forking this from [1].
>
> In that thread, Tom had asked if it wouldn't be better to find a new
> place to put extraUpdatedCols [2] instead of RangeTblEntry, along with
> the permission-checking fields are now no longer stor
On Wed, Dec 7, 2022 at 8:54 PM Amit Langote wrote:
> Per Alvaro's advice, forking this from [1].
>
> In that thread, Tom had asked if it wouldn't be better to find a new
> place to put extraUpdatedCols [2] instead of RangeTblEntry, along with
> the permission-checking fields are now no longer stor
12 matches
Mail list logo
