[HACKERS] TAP: allow overriding PostgresNode in get_new_node - Mailing list pgsql-hackers

From Craig Ringer
Subject [HACKERS] TAP: allow overriding PostgresNode in get_new_node
Date
Msg-id CAMsr+YF8kO+4+K-_U4PtN==2FndJ+5Bn6A19XHhMiBykEwv0wA@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Hi all

More and more I'm finding it useful to extend PostgresNode for project
specific helper classes. But PostgresNode::get_new_node is a factory
that doesn't provide any mechanism for overriding, so you have to
create a PostgresNode then re-bless it as your desired subclass. Ugly.

The attached patch allows an optional second argument, a class name,
to be passed to PostgresNode::get_new_node . It's instantiated instead
of PostgresNode if supplied. Its 'new' constructor must take the same
arguments.

BTW, it strikes me that we should really template a Perl file with the
postgres version. Or finally add a --version-num to pg_config so we
don't have to do version parsing. When you're writing extension TAP
tests you often need to know the target postgres version and parsing
our version strings, already annoying, got even more so with Pg 10. I
prefer adding --version-num to pg_config. Any objections? Will submit
patch if none.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Adding support for Default partition in partitioning
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Segmentation fault when creating a BRIN, 10beta1