On 2013-01-08 14:53:29 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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)
> > 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.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: james||Date: 2013-01-08 20:07:12|
|Subject: Re: json api WIP patch|
|Previous:||From: David Fetter||Date: 2013-01-08 19:53:38|
|Subject: Re: Cascading replication: should we detect/prevent cycles?|