Skip site navigation (1) Skip section navigation (2)

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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Date: 2013-01-08 22:40:29
Message-ID: 20130108224029.GA29936@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-08 17:28:33 -0500, Robert Haas wrote:
> On Tue, Jan 8, 2013 at 3:00 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > Uhm, we don't have & need palloc support and I don't think
> > relpathbackend() is a good justification for adding it.
>
> FWIW, I'm with Tom on this one.  Any meaningful code sharing is going
> to need that, so we might as well bite the bullet.

Yes, if we set the scope bigger than xlogreader I aggree. If its
xlogreader itself I don't. But as I happen to think we should share more
code...
Will prepare a patch.

I wonder whether it would be acceptable to make palloc() an actual
function instead of

#define palloc(sz)      MemoryContextAlloc(CurrentMemoryContext, (sz))

so we don't have to expose CurrentMemoryContext?

Alternatively we can "just" move the whole of utils/mmgr/* to port, but
that would imply an elog/ereport wrapper...

> And functions that return static buffers are evil incarnate.  I've
> spent way too much of my life dealing with the supreme idiocy that is
> fmtId().  If someone ever finds a way to make that go away, I will buy
> them a beverage of their choice at the next conference we're both at.

Imo it depends on the circumstances and number of possible callers, but
anyway, it seems to be already decided that my suggestion isn't the way
to go.

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2013-01-08 22:48:55
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous:From: Alvaro HerreraDate: 2013-01-08 22:37:01
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group