Re: [HACKERS] Custom allocators in libpq
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Custom allocators in libpq |
Дата | |
Msg-id | 17499.1503947486@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [HACKERS] Custom allocators in libpq (Aaron Patterson <tenderlove@ruby-lang.org>) |
Ответы |
Re: [HACKERS] Custom allocators in libpq
Re: [HACKERS] Custom allocators in libpq |
Список | pgsql-hackers |
Aaron Patterson <tenderlove@ruby-lang.org> writes: > I would like to be able to configure libpq with custom malloc functions. I can see the potential value of this ... > This patch doesn't replace all malloc calls to the configured ones, just > the mallocs related to creating result objects (which is what I'm > concerned with). ... but it seems like you're giving up a lot of the possible uses if you don't make it apply uniformly. I admit I'm not sure how we'd handle the initial creation of a connection object with a custom malloc. The obvious solution of requiring the functions to be specified at PQconnect time seems to require Yet Another PQconnect Variant, which is not very appetizing. I also wonder whether you wouldn't want a passthrough argument. For instance, one of the use-cases that springs to mind immediately is teaching postgres_fdw and dblink to use this so that their result objects are palloc'd not malloc'd, allowing removal of lots of PG_TRY overhead. While I suppose we could have the hook functions always allocate in CurrentMemoryContext, it'd likely be useful to be able to specify "use context X" at creation time. regards, tom lane
В списке pgsql-hackers по дате отправления: