Ideally this should come with a test case.

Technically this would need to go into 6.x, as the signature change is not backwards compatible. If it's considered low risk, then maybe it could go into 5.next.

Technically this would need to go into 6.x, as the signature change is not backwards compatible.

Why isn't it though? All call sites that were valid before are still valid. The addition is new semantic meaning to a newly supported type. We don't have a clear example of 'adding nullability' in our backwards compatibility guide but perhaps it is time we decide on that.

I agree on this going to 5.next though as it isn't a bugfix.

I've added a test, and I'm not sure I understand the workflow this change would enable. Any examples you could share?

sorry, been I'll. yes, I have an example that prompted this tweak. I'll drop that here in the morning.

Technically this would need to go into 6.x, as the signature change is not backwards compatible.

Why isn't it though? All call sites that were valid before are still valid. The addition is new semantic meaning to a newly supported type. We don't have a clear example of 'adding nullability' in our backwards compatibility guide but perhaps it is time we decide on that.

I agree on this going to 5.next though as it isn't a bugfix.

Now that we have actually typed arguments, adding a type (null or otherwise) would break all overridden methods, and so far breaking a public API in this was always considered not BC?

here is an example for where/why resetting the CTE was useful. Existing paginator has memory issues with large MSSQL datasets.

@markstory
Anything blocking this?

Anything blocking this?

Not really. However, it is currently targetting 5.x. Is this too much new behavior for a bugfix release?