GSoC 2026 - Add support for generate_series in PostgreSQL

Mentorship Google Season of Code
1

This project is rated “Hard,” and after diving into the ORM internals, I can see why. I’d like to share my technical findings and proposed roadmap to get early feedback before I finalize my formal proposal draft.

1. The Foundation: Generic Composite Fields

The project description mentions composite field support as a “stepping stone.” I’ve been studying the recent CompositePrimaryKey work and ColPairs in django/db/models/expressions.py.

My plan is to generalize this logic into a CompositeField primitive. This would allow the ORM to handle multiple columns from a single expression, providing the necessary “unpacking” logic in SQLCompiler.composite_fields_to_tuples. This is essential for handling the multi-column output that generate_series can produce.

2. The Hurdle: Expression-Based Table Sources

The core difficulty I’ve identified is that the Join and BaseTable classes in django/db/models/sql/datastructures.py are currently hard-coded to expect a table_name as a string.

Because generate_series is an expression (a function call), the current as_sql methods—which use compiler.quote_name_unless_alias(self.table_name)—would incorrectly quote the function call as a literal table name.

Proposed Solution: I intend to propose a new Joinable primitive (or extend existing ones) that accepts an Expression as a source. This would allow the compiler to resolve function arguments safely and correctly generate SQL like FROM generate_series(...) AS series.

3. Advanced Goal: LATERAL Join Support

Following Simon Charette’s advice, I also want to explore implementing LATERAL join support. This would require adding a lateral flag to the new Joinable class and teaching the SQLCompiler to prepend the LATERAL keyword when appropriate.

Proposed Roadmap Summary:

  • Phase 1: Generalize CompositeField to support multi-column bundles beyond just primary keys.
  • Phase 2: Implement the Relation / Expression-based Join architecture.
  • Phase 3: Implement the GenerateSeries expression in contrib.postgres and add LATERAL support.

I would appreciate any feedback on whether this architectural direction aligns with the mentors’ vision for the project. Specifically, should I focus more on the generic CompositeField first, or are there other “Set-Returning Function” primitives I should consider?