Re: BUG #19063: Heavily nesting trivial ROW projections produces out of memory error
От | Tom Lane |
---|---|
Тема | Re: BUG #19063: Heavily nesting trivial ROW projections produces out of memory error |
Дата | |
Msg-id | 3455128.1758739409@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #19063: Heavily nesting trivial ROW projections produces out of memory error (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #19063: Heavily nesting trivial ROW projections produces out of memory error
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > I don't understand how such excessive memory consumption is produced by such > a "simple" query. Compare regression=# select row(row(1)); row --------- ("(1)") (1 row) regression=# select row(row(row(1))); row --------------- ("(""(1)"")") (1 row) regression=# select row(row(row(row(1)))); row ------------------------- ("(""(""""(1)"""")"")") (1 row) Each layer of ROW() has to quote the string representing the next lower layer, so it doubles all the double-quotes per the quoting rules at https://www.postgresql.org/docs/current/rowtypes.html#ROWTYPES-IO-SYNTAX So the output length nearly doubles for each layer of ROW(), and yes it doesn't take that many layers to get to something excessive. Maybe we could redefine the quoting rules in a way that's friendlier to this sort of thing, but it would surely make them a lot more complicated, which would likely introduce enough client-side bugs to make the change unattractive. Not to mention the whole backwards compatibility question. On the whole I can't get excited about this, since I see no very good reason to use such a data structure. regards, tom lane
В списке pgsql-bugs по дате отправления: