Re: BUG #18877: PostgreSQL triggers assertion failure
От | Tom Lane |
---|---|
Тема | Re: BUG #18877: PostgreSQL triggers assertion failure |
Дата | |
Msg-id | 2461845.1743865979@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18877: PostgreSQL triggers assertion failure (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | 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
В списке pgsql-bugs по дате отправления: