Hi everyone,
I am William. I am an Electronics Engineering Student, currently working as a Python Programming Intern, and I am working on heavily data-driven backend applications. I am highly interested in contributing to the Add support for generate_series in postgres project under GSoC 2026.
After going through some of the previous forum discussions (@charettes’ insights on virtual tables), I believe the task is not just about patching the generate_series function. It is actually about the architecture because the problem lies with the fact that the ORM does not support the appropriate primitives for set-returning functions and LATERAL JOINs.
In my recent backend-related activities, like creating a stock portfolio tracker and dealing with simulations of financial data, I have witnessed the importance of time series data generation and gap filling firsthand.
I would really love to contribute to the project under GSoC 2026 and work on the above-mentioned problem so that the ORM supports expressions with a return value. I have different ideas to contribute concerning this that definitely be helpful
Before I work on the GSoC application, I would like to get the mentors’ opinions on a few things:
Should the 350 hours be focused on getting the generate_series function working correctly, or should the work heavily focus on creating a generic relation expression so that we can support other SRFs in the future?
Are there any specific open tickets related to ORM aliases that I should probably focus on right away as a ‘good first issue’ to you know, get a feel for the compiler logic?
Looking forward to receiving the feedback and contributing to ORM!
Best regards,
William
Hello William, excited to hear about your interest in GSoC for this topic.
In my opinion the main priority here would be to add generic support support for CompositeField as that would pave the door, amongst other things, to have expression define that they return tuples of fields.
Today there are few cases where we fake the output_field of expressions or have to resort to manual subqueries wrapping (e.g. during aggregation) which we could do away with if we had CompositeField.
Members of sql.Query.alias_map which are either BaseTable or Join could define their own output_field which would make it easier to compose complex joins scenarios, CTEs, and implement methods a such as as_subquery because the generation of the SQL associated with the FROM clause members would be delegated to the expressions instead of hardcoded in the compiler.
This would allow the lookup resolving logic of Query be changed from starting from self.model to self.base_table.output_field and pave the door to moving tons of hardcoded Query logic to Expression.resolve_expression.
Official set returning functions, which behave closely to subqueries, could then be built on top of that by having annotations of them result in LATERAL JOIN pushdown if they are not singleton.
Thank you, Simon! This clarifies the scope perfectly.
I get the idea of the 350-hour project being more about the underlying ORM architecture and less about generate_series as a standalone feature. Introducing the concept of CompositeField for dealing with expressions that return tuples makes perfect sense, though.
The idea of delegating the SQL generation from the compiler down to the expressions through resolve_expression and output_field of the alias_map class members is a great approach. I see exactly how the groundwork being laid here enables the natural resolution of SRFs through the use of LATERAL JOIN pushdowns.
To ensure the proper scoping of my initial proposal, I’ll revise the django/db/models/sql/query. pylogic again to see the transition of the lookup resolving logic from self. model to self.base_table.output_field.
Hi Simon,
Thank you for the guidance. I also just saw and acknowledged your response on the forum. It totally makes sense to focus on the ORM architecture instead of a specific feature like generate_series.
Making CompositeField work nicely to deal with expressions that return tuples and refactoring SQL generation from the compiler to resolve_expression is a good strategy. I can definitely see why you’d do that to lay the groundwork for SRFs to just work as a natural fit using LATERAL JOIN pushdowns.
I look forward to working further on this and learning from you.
Cheers,
William