Re: Testing of MVCC
От | Andrew Dunstan |
---|---|
Тема | Re: Testing of MVCC |
Дата | |
Msg-id | 43020153.7070308@dunslane.net обсуждение исходный текст |
Ответ на | Re: Testing of MVCC (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Testing of MVCC
Re: Testing of MVCC Re: Testing of MVCC |
Список | pgsql-hackers |
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>Tom Lane wrote: >> >> >>>Maybe the right answer is just to hack up Pg.pm or DBD::Pg to provide >>>the needed asynchronous-command-submission facility, and go forward >>>from there using the Perl Test framework. >>> >>> > > > >>How will we make sure it's consistent? People have widely varying >>versions of DBD::Pg and DBI installed, not to mention the bewildering >>array of Test::Foo modules out there >> >> > >Yeah, that would be an issue. But can't a Perl script require >"version >= m.n" for each module it uses? > > Yes it can, but are you going to restrict building or running regressions to only thos platforms that have our required modules installed? That might be thought a tad unfriendly. >I had actually been thinking to myself that Pg.pm might be a better base >because it's more self-contained. > >Another line of thought is to write a fresh implementation of the wire >protocol all in Perl, so as not to depend on DBI or much of anything >except Perl's TCP support (which I hope is reasonably well standardized >;-)). If you wanted to do any testing at the protocol level --- >handling of bad messages, say --- you'd pretty much need this anyway >because no driver is going to let you get at things at such a low level. >But it'd raise the cost of getting started quite a bit. > > I think we're mostly on the same page. Maybe pulling some code from this would give us a leg up rather than having to start from scratch: http://search.cpan.org/~arc/DBD-PgPP-0.05/ cheers andrew
В списке pgsql-hackers по дате отправления: