Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Дата
Msg-id 23440.1357674809@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@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.

> 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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Cascading replication: should we detect/prevent cycles?
Следующее
От: David Fetter
Дата:
Сообщение: Re: Cascading replication: should we detect/prevent cycles?