Thread: 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