# GSoC 2026 - Add support for generate\_series in PostgreSQL

**URL:** https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgresql/44409
**Category:** Google Season of Code
**Created:** [March 7, 2026, 7:04pm UTC](https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgresql/44409 "2026-03-07T19:04:38Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![RealOrangeKun](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/realorangekun/32/31797_2.png) [@RealOrangeKun](https://forum.djangoproject.com/u/RealOrangeKun)
#### Post date: [March 7, 2026, 7:04pm UTC](https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgresql/44409/1 "2026-03-07T19:04:38Z")

</div>

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?