Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node
Дата
Msg-id 5938AB86.1090708@anastigmatix.net
обсуждение исходный текст
Ответ на Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: [HACKERS] TAP: allow overriding PostgresNode in get_new_node  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Notes on testing Postgres 10b1
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: [HACKERS] Notes on testing Postgres 10b1