Re: Don't deform column-by-column in composite_to_json
От | Alvaro Herrera |
---|---|
Тема | Re: Don't deform column-by-column in composite_to_json |
Дата | |
Msg-id | 20190206015337.GA3854@alvherre.pgsql обсуждение исходный текст |
Ответ на | Don't deform column-by-column in composite_to_json (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Don't deform column-by-column in composite_to_json
|
Список | pgsql-hackers |
On 2019-Feb-01, Andres Freund wrote: > diff --git a/src/backend/utils/adt/json.c b/src/backend/utils/adt/json.c > index de0d0723b71..8724022df54 100644 > --- a/src/backend/utils/adt/json.c > +++ b/src/backend/utils/adt/json.c > @@ -1755,6 +1755,8 @@ composite_to_json(Datum composite, StringInfo result, bool use_line_feeds) > int i; > bool needsep = false; > const char *sep; > + Datum values[MaxHeapAttributeNumber]; > + bool nulls[MaxHeapAttributeNumber]; > > sep = use_line_feeds ? ",\n " : ","; Isn't this putting much more than needed in the stack? Seems like we could just allocate tupdesc->natts members dynamically. Not sure if we care: it's about 12 kB; maybe considering palloc overhead, using the stack is better. Worth asking. But if this is worth doing here, then it's worth doing in a lot more places, isn't it? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: