Re: 9.6 TAP tests and extensions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 9.6 TAP tests and extensions
Дата
Msg-id 26378.1474661072@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 9.6 TAP tests and extensions  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: 9.6 TAP tests and extensions  (Craig Ringer <craig@2ndquadrant.com>)
Re: 9.6 TAP tests and extensions  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> On 23 September 2016 at 00:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Certainly there are restrictions, but I'd imagine that every new release
>> will be adding features to the TAP test infrastructure for some time to
>> come.  I think it's silly to claim that 9.6 is the first branch where
>> TAP testing is usable at all.

> Also, despite what I said upthread, there's no need for normal
> PGXS-using extensions to define their $(prove_installcheck)
> replacement. It works as-is. The problems I was having stemmed from
> the fact that I was working with a pretty nonstandard Makefile without
> realising that the changes were going to affect prove. $(prove_check)
> isn't useful from extensions of course since it expects a temp install
> and PGXS doesn't know how to make one, but $(prove_installcheck) does
> the job fine.

> It's thus sufficient to apply the patch to install the perl modules to
> 9.4, 9.5 and 9.6. Nothing else is needed. I've attached backports for
> 9.4 and 9.5.

Pushed with cosmetic adjustments --- mostly, I followed the project
standard that makefiles are named Makefile.  (We use a GNUmakefile
only in directories where it seems likely that non-developers would
invoke make by hand, and there's supposed to be a Makefile beside them
that throws an error whining about how you're not using GNU make.
I see no need for that in src/test/perl.)

Looking back over the thread, I see that you also proposed installing
isolationtester and pg_isolation_regress for the benefit of extensions.
I'm very much less excited about that idea.  It'd be substantially more
dead weight in typical installations, and I'm not sure that it'd be useful
to common extensions, and I'm not eager to treat isolationtester's API
and behavior as something we need to hold stable for extension use.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: store narrow values in hash indexes?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: store narrow values in hash indexes?