Re: Re: PATCH: The linker complains about the '-bundle_loader "../../src/backend/postgres"' against PostgreSQL 8.4 on OSX

On Mon, May 7, 2012 at 11:46 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 07.05.2012 13:39, Dave Page wrote:
>>
>> On Mon, May 7, 2012 at 11:33 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com>  wrote:
>>
>>> for that matter. I'll fix this in git master. I consider the current tip
>>> of
>>> the old CVS repository (or the corresponding checkout from the git repo)
>>> to
>>> be the latest stable release, PostgreSQL one-click installers<= 9.1 can
>>> continue to use that version.
>>
>>
>> Can you create a "PRE-9_2" branch for the current architecture, and
>> apply Ashesh's patch to that if you think it's a reasonable fix
>> please? We can then move the older builds to that branch. Then the 9.2
>> changes can go on master.
>
>
> By current architecture, do you mean what we had in the CVS, or as the code
> stands in the current tip of the git repository? I agree we should create a
> branch like that, but I want to make sure we agree on where it should be
> branched off. I've rearranged and cleaned up the code quite extensively in
> git master already, and I'm not sure if we want to include all that in
> back-branches. On one hand, I've fixed a lot of bugs with the changes, so it
> would be nice to include those fixes, but OTOH, perhaps we shouldn't risk
> destabilizing back-branches.

What's at the current tip. I'm happy with those changes in the back
branches - they're really mostly just bug fixes and relatively minor
architectural tweaks as I understood them. It's the move to a single
library that I don't want in the back branches.

> Then again, we can probably be more aggressive
> with pushing changes to pldebugger to back-branches, as it's not something
> you should be running in production anyway. It's just a development tool.

Agreed.

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company