From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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 20:39:57 |
Message-ID: | 20130108203957.GB10185@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-01-08 15:27:23 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > Uhm, we don't have & need palloc support and I don't think
> > relpathbackend() is a good justification for adding it.
>
> I've said from the very beginning of this effort that it would be
> impossible to share any meaningful amount of code between frontend and
> backend environments without adding some sort of emulation of
> palloc/pfree/elog. I think this patch is just making the code uglier
> and more fragile to put off the inevitable, and that we'd be better
> served to bite the bullet and do that.
If you think relpathbackend() alone warrants that, yes, I can provide a
wrapper. Everything else is imo already handled in a sensible and not
really ugly manner? Imo its not worth the effort *for this alone*.
I already had some elog(), ereport(), whatever emulation but Heikki
preferred not to have it, so its removed by now.
To what extent do you want palloc et al. emulation? Provide actual pools
or just make redirect to malloc and provide the required symbols (at the
very least CurrentMemoryContext)?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-01-08 20:42:05 | Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend |
Previous Message | Alvaro Herrera | 2013-01-08 20:38:20 | Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it |