Re: Initializing Datums for use with SPI_execute_plan
От | Jack Orenstein |
---|---|
Тема | Re: Initializing Datums for use with SPI_execute_plan |
Дата | |
Msg-id | 7ecd811f0609191300h41d0c21ajca43f64510b79e35@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Initializing Datums for use with SPI_execute_plan (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Initializing Datums for use with SPI_execute_plan
Re: Initializing Datums for use with SPI_execute_plan |
Список | pgsql-general |
On 9/19/06, Martijn van Oosterhout <kleptog@svana.org> wrote: > On Tue, Sep 19, 2006 at 01:27:56PM -0400, Jack Orenstein wrote: > > On 9/18/06, Jack Orenstein <jack.orenstein@gmail.com> wrote: > > >---------- Forwarded message ---------- > > >From: Andrew - Supernews <andrew@supernews.net> > > ... > > > Jack> I have an int8 that I need as a Datum for use with > > > Jack> SPI_execute_plan. > > > > > >Int64GetDatum(your_variable) > > > > which then has to be pfree'd, correct? > > Possibly, it probably depends on the architechture. The memory is being > allocated in a per-call context IIRC so it'll be freed at the end of > the function anyway. I wouldn't worry about it. Can you provide some guidance (or point to some documentation) on how to manage memory? Is the idea that I should (must?) not pfree palloc'ed memory from Int64GetDatum, but I should free anything I allocate myself using palloc? Or not even that? The C extension I'm writing, which uses the SPI, will be called thousands or millions of times as part of a data conversion -- I do have to worry about memory leaks. Once the conversion completes, I won't use the function any longer. But I'd rather not leak memory and have to do something drastic to reclaim it, such as bouncing postgresql. Jack
В списке pgsql-general по дате отправления: