Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree) - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)
Date
Msg-id 54EE717C.4040901@BlueTreble.com
Whole thread Raw
In response to Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 2/24/15 1:23 AM, Michael Paquier wrote:
>
>
> On Mon, Feb 23, 2015 at 9:31 PM, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
>
>     > On Feb 22, 2015, at 5:41 AM, Michael Paquier <michael.paquier@gmail.com <mailto:michael.paquier@gmail.com>>
wrote:
>     > This is up to the maintainer of each extension to manage their code
>     > tree. However I can imagine that some people would be grateful if we
>     > allow them to not need sql/ and expected/ containing only one single
>     > .gitignore file ignoring everything with "*", making the code tree of
>     > their extensions cleaner.
>
>     I don't see this as an improvement. What's wrong with a .gitignore
>     file ignoring everything?
>
>
> That's mainly a matter of code maintenance style (and I am on the side
> that a minimum number of folders in a git tree makes things easier to
> follow), and IMO it is strange to not have some flexibility. Btw, the
> reason why this patch exists is this thread of last December:
> http://www.postgresql.org/message-id/flat/20141212134508.GT1768@alvh.no-ip.org#20141212134508.GT1768@alvh.no-ip.org

What's an example of this? I ask because what I'd like is to break the 
cluster management portion of pg_regress out on it's own to make it easy 
to get that functionality while using a different test framework (like 
pgTap).
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Next
From: Amit Langote
Date:
Subject: Re: Partitioning WIP patch