Horton
Menu

Re: Row pattern recognition

Henson Choi <assam258@gmail.com>

View thread
From: Henson Choi <assam258@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com, peter@eisentraut.org, pgsql-hackers@postgresql.org
Date: 2026-03-03T11:32:51Z
Lists: pgsql-hackers 
Hi,Tatsuo

While reviewing the RPR test cases, I noticed that a subquery filter
on RPR window function results silently returns wrong results.

For example, given this query:

  SELECT * FROM (
      SELECT id, val, COUNT(*) OVER w as cnt
      FROM rpr_copy
      WINDOW w AS (
          ORDER BY id
          ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
          PATTERN (A B?)
          DEFINE A AS val > 10, B AS val > 20
      )
  ) sub
  WHERE cnt > 0
  ORDER BY id;

This should return 2 rows, but returns 0 rows instead.

The EXPLAIN plan shows that "cnt > 0" is pushed down into the
WindowAgg node as a Run Condition:

  WindowAgg
    Run Condition: (count(*) OVER w > 0)    <-- pushed down
    ->  Sort
          ->  Seq Scan on rpr_copy

I will investigate the cause and work on a fix.

Best regards,
Henson

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Adjust cross-version upgrade tests for seg_out() fix

  2. Rationalize error comments in partition split/merge tests

  3. Add fast path for foreign key constraint checks

  4. Fix assorted pretty-trivial memory leaks in the backend.

  5. Add temporal FOREIGN KEY contraints

  6. Add trailing commas to enum definitions

  7. Remove obsolete executor cleanup code