Обсуждение: Inheriting PostgresNode object

Hi hackers!

I've encountered need to extend functionality of PostgresNode class
from the TAP test framework. What I want can easily be done via perl
object inheritation. 

But documentation in the PostgresNode.pm recommends to use get_new_node
function rather than call PostgresNode constructor directly.

I see following ways to solve this problem:

1. Ignore this recommendation and write new class which calls
SUPER->new() from the constructor and call its constructor directly

2. Get the PostgresNode object from get_new_node function and bless it
into new class

3. Use delegation instead of inheritance. This would require some black
magic with AutoLoader module to avoid writing wrapper for each
PostgresNode method.

Which approach would people recommend to take?

--                                   Victor Wagner <vitus@wagner.pp.ru>

Victor Wagner wrote:
> Hi hackers!
> 
> I've encountered need to extend functionality of PostgresNode class
> from the TAP test framework. What I want can easily be done via perl
> object inheritation. 
> 
> But documentation in the PostgresNode.pm recommends to use get_new_node
> function rather than call PostgresNode constructor directly.

Yeah, as I recall the only thing the get_new_node thingy does is assign
a nonconflicting port number to each instance, and make sure the
instances are all teared down at END.  I don't remember now why didn't
we just do the port check in the constructor, but we messed with that
code a lot after the commit.  Maybe there's no good reason and we should
change that, for convenience of inheritance.  As for the teardown, I
remember trying to do that using DESTROY instead of an END block, but
there was some problem I couldn't figure out (I think there was some
ugly warning message because the data dir for the node was removed
before the DESTROY for the object had the chance to run)... maybe you
can figure that one out.

Overall I think it'd be an improvement to use a regular constructor
instead of the current arrangement.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Yeah, as I recall the only thing the get_new_node thingy does is assign
> a nonconflicting port number to each instance, and make sure the
> instances are all teared down at END.  I don't remember now why didn't
> we just do the port check in the constructor, but we messed with that
> code a lot after the commit.  Maybe there's no good reason and we should
> change that, for convenience of inheritance.  As for the teardown, I
> remember trying to do that using DESTROY instead of an END block, but
> there was some problem I couldn't figure out (I think there was some
> ugly warning message because the data dir for the node was removed
> before the DESTROY for the object had the chance to run)... maybe you
> can figure that one out.

We changed that in 08af92190 --- changing it back would require
finding a different solution to the order-of-shutdown problem.

> Overall I think it'd be an improvement to use a regular constructor
> instead of the current arrangement.

Constructor si, destructor no.
        regards, tom lane