On 22/12/2021 20:42, Tom Lane wrote:
Andrey Lepikhov writes:
On 5/2/2020 01:24, Tom Lane wrote:
I've not written any actual code, but am close to being ready to.
This thread gives us hope to get started on solving some of the basic
planner problems.
But there is no activity for a long time,
Andrey Lepikhov writes:
> On 5/2/2020 01:24, Tom Lane wrote:
>> I've not written any actual code, but am close to being ready to.
> This thread gives us hope to get started on solving some of the basic
> planner problems.
> But there is no activity for a long time, as I see. Have You tried to
>
On 5/2/2020 01:24, Tom Lane wrote:
I've not written any actual code, but am close to being ready to.
This thread gives us hope to get started on solving some of the basic
planner problems.
But there is no activity for a long time, as I see. Have You tried to
implement this idea? Is it actual no
Robert Haas writes:
> On Fri, Dec 20, 2019 at 11:13 AM Tom Lane wrote:
>> The alternatives that seem plausible at this point are
>> (1) Create some sort of wrapper node indicating "the contents of this
>> expression might be replaced by NULL". This is basically what the
>> planner's PlaceHolderV
I wrote:
> Here is a further step on this journey. It's still just parser
> refactoring, and doesn't (AFAICT) result in any change in generated
> parse trees, but it seems worth posting and committing separately.
Pushed at 5815696bc.
> 2. Add per-column information to the ParseNamespaceItems. A
I wrote:
> Anyway, I had started to work on getting parse analysis to label
> outer-join-nullable Vars properly, and soon decided that no matter how
> we do it, there's not enough information available at the point where
> parse analysis makes a Var. The referenced RTE is not, in itself,
> enough
Hi,
On 2019-12-20 11:12:53 -0500, Tom Lane wrote:
> (2) Explicitly mark Vars as being nullable by some outer join. I think
> we could probably get this down to one additional integer field in
> struct Var, so it wouldn't be too much of a penalty.
I've for a while wished that we could, e.g. so ex
Robert Haas writes:
> On Fri, Dec 20, 2019 at 11:13 AM Tom Lane wrote:
>> The alternatives that seem plausible at this point are
>> ...
>> (2) Explicitly mark Vars as being nullable by some outer join. I think
>> we could probably get this down to one additional integer field in
>> struct Var, s
On Fri, Dec 20, 2019 at 11:13 AM Tom Lane wrote:
> The alternatives that seem plausible at this point are
>
> (1) Create some sort of wrapper node indicating "the contents of this
> expression might be replaced by NULL". This is basically what the
> planner's PlaceHolderVars do, so maybe we'd jus
I wrote:
> I started to think a little harder about the rough ideas I sketched
> yesterday in [1] about making the planner deal with outer joins in
> a less ad-hoc manner.
> [1] https://www.postgresql.org/message-id/7771.1576452845%40sss.pgh.pa.us
After further study, the idea of using join alias
Robert Haas writes:
> On Mon, Dec 16, 2019 at 12:00 PM Tom Lane wrote:
>> What I'd like, in order to make progress with the planner rewrite,
>> is that all four Vars in the tlist have varno 3, showing that
>> they are (potentially) semantically distinct from the Vars in
>> the JOIN ON clause (whi
On Mon, Dec 16, 2019 at 12:00 PM Tom Lane wrote:
> What I'd like, in order to make progress with the planner rewrite,
> is that all four Vars in the tlist have varno 3, showing that
> they are (potentially) semantically distinct from the Vars in
> the JOIN ON clause (which'd have varnos 1 and 2 in
12 matches
Mail list logo
