Re: TAP: allow overriding PostgresNode in get_new_node

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP: allow overriding PostgresNode in get_new_node
Date: 2017-06-08 01:42:30
Message-ID: 5938AB86.1090708@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/02/17 15:51, Chapman Flack wrote:
> But what it buys you is then if your MyExtraPGNode has PostgresNode
> as a base, the familiar idiom
>
> MyExtraPGNode->get_new_node('foo');
>
> works, as it inserts the class as the first argument.
>
> As a bonus, you then don't need to complicate get_new_node
> with a test for (not ($node->isa("PostgresNode"))) because
> if it weren't, it wouldn't have inherited get_new_node

Any takers if I propose this amendment in the form of a patch?

Relying on the perl idiom instead of a $node->isa() test shortens
the patch; does that ameliorate at all the concern about complicating
core for the benefit of modules?

I'm not fully persuaded that just re-blessing a PostgresNode suffices
as a workaround ... if the subclass expects to have additional state
set up by its own constructor, the deception seems likely to be exposed.
So I think there are more than just cosmetic grounds for allowing this.

-Chap

Attachment Content-Type Size
PostgresNode-get_new_node-can-be-classmethod-v1.patch text/x-patch 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2017-06-08 01:50:54 Re: Notes on testing Postgres 10b1
Previous Message Peter Eisentraut 2017-06-08 01:37:02 Re: Notes on testing Postgres 10b1