Thread: SPI_psprintf and SPI_pstrdup
The Apache runtime library, which is using a similar concept for allocating heap-based memory out of a pool, has some since utility functions, named apr_psprintf and apr_pstrdup. These functions allocate a memory-block out of a pool and print a formatted string into that block, or duplicate a string respectively. Since such useful functions are missing in PostgreSQL's Server Programming Interface, I created two similar functions: char *SPI_psprintf(const char *fmt, ...); allocates a block of memory out of the memory pool and prints a formatted string into it SPI_pstrdup(const char *src); allocates a block of memory out of the memory pool and copies an existing string into it. I includes a patch containing these functions to be applied onto version 8.2.3 and 8.2.4. I would appreciate seeing it in one of the next versions. Jacob Rief
Attachment
Jacob Rief wrote: > char *SPI_psprintf(const char *fmt, ...); > allocates a block of memory out of the memory pool and prints a > formatted string into it Such matters are best solved using the StringInfo API. > SPI_pstrdup(const char *src); > allocates a block of memory out of the memory pool and copies an > existing string into it. How is that different from pstrdup()? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Jacob Rief <jacob.rief@gmx.at> writes: > The Apache runtime library, which is using a similar concept for > allocating heap-based memory out of a pool, has some since utility > functions, named apr_psprintf and apr_pstrdup. SPI_palloc might possibly be worth the trouble, but the other thing is duplicative of the StringInfo routines, and I do not think it's a good idea to provide duplicate ways to accomplish the same thing. It's just more code to maintain and more things for newcomers to learn about when trying to read someone else's code. Also, proposed API additions without any documentation are not acceptable. The docs addition for SPI_palloc would be substantially larger than the code itself; is it worth the trouble? regards, tom lane