Re: Runtime SHAREDIR for testing CREATE EXTENSION - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Runtime SHAREDIR for testing CREATE EXTENSION
Date
Msg-id CAAZKuFbqetmyhE0mDYffaUQ7Cnh1iTjcHF6Q8hK1xkD2e0JYng@mail.gmail.com
Whole thread Raw
In response to Re: Runtime SHAREDIR for testing CREATE EXTENSION  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Runtime SHAREDIR for testing CREATE EXTENSION  (Andrew Dunstan <andrew@dunslane.net>)
Re: Runtime SHAREDIR for testing CREATE EXTENSION  (Maciek Sakrejda <m.sakrejda@gmail.com>)
List pgsql-hackers
On Fri, Feb 24, 2012 at 10:21 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On fre, 2012-02-24 at 17:26 +0100, Sandro Santilli wrote:
>> We don't initdb with PostGIS regression testing framework
>> but I've considered doing it for this specific case and it stroke me
>> that even then we couldn't control SHAREDIR.
>
> I would always create a new instance using initdb for test runs.  It's
> easy and avoids all these problems.

Having been in this position once before in a different but similar
situation, there's one big caveat: initdb is *really* slow, so it is
really painful for people who write Postgres-linked code that is
compiled separately, whereby the initdb binary is stable.  The
frustration is not unlike when I have to run ./configure, except I had
to do it all the time, every time.

A ccache-like solution has worked well for at least one person I know,
and wasn't hard to implement(?) for personal use.

But by hook or crook, a fresh database is the "right" thing for sure.

--
fdr


pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Command Triggers, patch v11
Next
From: Thom Brown
Date:
Subject: Re: Command Triggers, patch v11