On 2013-01-08 14:53:29 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2013-01-08 14:28:14 -0500, Tom Lane wrote: > >> I'm 100% unimpressed with making relpathbackend return a pointer to a > >> static buffer. Who's to say whether that won't create bugs due to > >> overlapping usages? > > > I say it ;). I've gone through all callers and checked. Not that that > > guarantees anything, but ... > > Even if you've proven it safe today, it seems unnecessarily fragile. > Just about any other place we've used a static result buffer, we've > regretted it, unless the use cases were *very* narrow.
Hm, relpathbackend seems pretty narrow to me. Funny, we both argued the other way round than we are now when talking about the sprintf(..., "%X/%X", (uint32)(recptr >> 32), (uint32)recptr) thingy ;) > > The reason a static buffer is better is that some of the *desc routines > > use relpathbackend() and pfree() the result. That would require > > providing a stub pfree() in xlogdump which seems to be exceedingly ugly. > > Why? If we have palloc support how hard can it be to map pfree to free? > And why wouldn't we want to? I can hardly imagine providing only palloc > and not pfree support. Uhm, we don't have & need palloc support and I don't think relpathbackend() is a good justification for adding it. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers