# GSoC 2026: Add support for generate\_series in postgres (Draft Proposal Feedback)

**URL:** https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgres-draft-proposal-feedback/44360
**Category:** Google Season of Code
**Created:** [March 2, 2026, 9:37pm UTC](https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgres-draft-proposal-feedback/44360 "2026-03-02T21:37:19Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![Samriddha9619](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/samriddha9619/32/29438_2.png) [@Samriddha9619](https://forum.djangoproject.com/u/Samriddha9619)
#### Post date: [March 16, 2026, 9:48am UTC](https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgres-draft-proposal-feedback/44360/2 "2026-03-16T09:48:11Z")

</div>

Following recent feedback on this forum post - [Post](https://forum.djangoproject.com/t/gsoc-2026-interest-in-adding-support-for-generate-series-in-postgres/44362/4)  
I’ve restructured my proposal to prioritize the foundational ORM primitives rather than jumping directly to SRF routing.

**Revised phased approach:**

1. **`CompositeField`** — Enabling expressions to declare tuple return types. The existing ColPairs (composite PK support) and `allows_composite_expressions` flag show the ORM is already moving in this direction.
2. **output\_field on `alias_map` members** — Having BaseTable and Join define their own output\_field so that lookup resolution in names\_to\_path() can transition from `self.model` → `self.base_table.output_field`. This delegates SQL generation to expressions instead of hardcoding it in the compiler.
3. **SRF support via LATERAL JOIN** — With the above foundations, a `TableValuedFunction` alias\_map member naturally integrates: add\_annotation() detects `set_returning=True`, routes the expression to `alias_map` with a `CompositeField` output, and replaces the annotation with a Col reference. The compiler emits `LATERAL generate_series(...)` in the FROM clause.

**One specific question:** Once Phase 2 makes `alias_map` members self-describing via

output\_field, would you expect `TableValuedFunction` to integrate through `Query.join()` (with a lightweight adaptation for members that lack `join_cols`), or is direct `alias_map` insertion with manual refcount management the cleaner approach? TVFs don’t participate in join deduplication or promotion, so I lean toward direct insertion — but I’d value your perspective on long-term maintainability.

**Updated AST ( Abstract Syntax Tree )**

```auto
User writes:
.annotate(series=GenerateSeries(1, 10)).filter(series__gt=5)
                               │
                               ▼
                  ┌────────────────────────┐
                  │ Query.add_annotation() │
                  │ (set_returning=True) │
                  └────────────┬───────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼ ▼
  [Phase 2: FROM clause] [Phase 1: SELECT/WHERE]
  alias_map["series"] = annotations["series"] =
  TableValuedFunction( Col("series",
    expr=GenerateSeries(1, 10), CompositeField(
    alias="series", IntegerField("value")
    output_field=CompositeField( )
      IntegerField("value") )
    )
  ) │
            │ │
            ▼ ▼
  get_from_clause() iterates resolve_ref("series")
  alias_map, calls as_sql() returns the Col object
            │ │
            ▼ ▼
  LATERAL generate_series(1, 10) "series"."value" > 5
  AS "series"("value")
 
 ─────────────────────────────────────────────────────────────
 FINAL SQL:
 SELECT "myapp_model"."id", "series"."value"
 FROM "myapp_model",
      LATERAL generate_series(1, 10) AS "series"("value")
 WHERE "series"."value" > 5
 ─────────────────────────────────────────────────────────────
```

---

_[View the full topic](https://forum.djangoproject.com/t/gsoc-2026-add-support-for-generate-series-in-postgres-draft-proposal-feedback/44360)._