3.0 Support REMOVE property in cost planner

[craigtaverner]

Since SET n.prop = null is semantically equivalent to removing a property, we planned this as a rewrite to SetProperty in the ClauseConversion phase.

[pontusmelke]

IMHO it would be nicer to have a proper RemoveProperty logical plan. Looking at the plans makes it feel somewhat inconsistent that we have SetLabels/RemoveLabels but only SetProperty.

[Mats-SX]

We should probably rename this propertiesSet parameter to propertiesWritten or something, because this is a bit confusing.

[craigtaverner]

Curiously the stats did not have a propertiesRemoved counter, so as far as they were concerned removal was seen as a set-property. I took this has a hint! :-)

[Mats-SX]

Yes, I saw that too, and that's why I made this comment.

[Mats-SX]

I agree with @pontusmelke, but implementation-wise I see that we can definitely reuse the runtime code (which we can not for labels, as they don't have this symmetry), and implement it as setting null, as long as the plan description in this case prints remove.

[craigtaverner]

Regarding the discussion of having a real RemoveProperty or fake RemovePropery in the plan description, should we differentiate between the user typing REMOVE n.prop or SET n.prop = null or SET n.prop = {param_that_is_null}. Currently all cases would look like a SET property. If we do Pontus suggestion, only the first would look like REMOVE, the others like SET. Mats suggestion would make the second one look like REMOVE if there was no auto-parameterization.

[Mats-SX]

I think it's perfectly reasonable to plan Remove for a query where we do see SET n.prop = null. That's even educational for the user.

[craigtaverner]

The problem is that this plan makes autoparameterization hide the remove. That seems unreasonable to me. Pontus approach of making REMOVE syntax have REMOVE plan, and SET syntax have SET plan is less confusing. But it is more code and hides the semantic equivalence.

[systay]

I think we should strive to have few and simple operators in our query plans. That makes it easier to build planners and runtimes working with these operators. So, in this case, I prefer a single operator that solves both problems. The ability of the user to recognise query parts in the logical plan is much less valuable, IMHO.