Re: BUG #18877: PostgreSQL triggers assertion failure
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: luy70@psu.edu, pgsql-bugs@lists.postgresql.org
Date: 2025-04-05T15:12:59Z
Lists: pgsql-bugs
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2025-Apr-05, Tom Lane wrote: >> So what we should be doing is building a parse-analysis result >> that deparses into something that looks like the input; probably, >> a JsonArrayQueryConstructor node with an analyzed EXPR_SUBLINK >> SubLink below it. Then we can make this tlist-length check against >> the analyzed SubLink, removing the problem of premature errors that >> are not spelled the way we want. > Sounds reasonable, I can try to find better coding for this, but it > won't be soon. I won't be sad if somebody else wants to do it, so if > you feel like it, please be my guest. Yeah, it's not high priority for me either. Maybe someone else will be interested in the project. >> Anyway, that idea is far too invasive to be back-patchable, >> and IMO it's too late to consider even getting it into v18. >> So what I'm thinking is we should just apply the copyObject >> hack for now, and resolve to reconsider this code later. > Sounds reasonable. OK, I'll get that done. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid double transformation of json_array()'s subquery.
- e33f2335a9d9 18.0 landed
- ca54f9b706f6 16.9 landed
- 717e8a1e5256 17.5 landed