Re: Row pattern recognition

Tatsuo Ishii <ishii@sraoss.co.jp>

From: Tatsuo Ishii <ishii@sraoss.co.jp>

To: jacob.champion@enterprisedb.com, vik@postgresfriends.org

Cc: pgsql-hackers@postgresql.org, er@xs4all.nl, peter@eisentraut.org

Date: 2024-04-28T11:28:26Z

Lists: pgsql-hackers

Commits

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

Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 cited
Remove obsolete executor cleanup code
- d060e921ea5a 17.0 cited

Attachments

v17-0001-Row-pattern-recognition-patch-for-raw-parser.patch (text/x-patch)

>> I think returning zero would match Vik's explanation upthread [1],
>> yes. Unfortunately I don't have a spec handy to double-check for
>> myself right now.
> 
> Ok. I believe you and Vik are correct.
> I am modifying the patch in this direction.

Attached are the v17 patches in the direction. Differences from v16
include:

- In 0005 executor patch, aggregation in RPR always restarts for each
  row. This is necessary to run aggregates on no matching (due to
  skipping) or empty matching (due to no pattern variables matches)
  rows to produce NULL (most aggregates) or 0 (count) properly. In v16
  I had a hack using a flag to force the aggregation results to be
  NULL in case of no match or empty match in
  finalize_windowaggregate(). v17 eliminates the dirty hack.

- 0006 docs and 0007 test patches are adjusted to reflect the RPR
  output chages in 0005.
  
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp