Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
От | Andres Freund |
---|---|
Тема | Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it |
Дата | |
Msg-id | 20130108193700.GC8311@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
|
Список | pgsql-hackers |
On 2013-01-08 14:28:14 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > maxpg> From: Andres Freund <andres@anarazel.de> > > relpathbackend() (via some of its wrappers) is used in *_desc routines which we > > want to be useable without a backend environment arround. > > 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 ... 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. > > Change signature to return a 'const char *' to make misuse easier to > > detect. > > That seems to create way more churn than is necessary, and it's wrong > anyway if the result is palloc'd. It causes warnings in potential external users that pfree() the result of relpathbackend which seems helpful. Obviously only makes sense if relpathbackend() returns a pointer into a static buffer... Greetings, Andres Freund --Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: