=?UTF-8?B?SXZhbiBQYW5jaGVua28=?= <wao@mail.ru> writes:
> Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < peter@eisentraut.org >:
>> If the transform deals with a built-in type, then they should just be
>> added to the respective pl extension directly.
> The new extension bytea_plperl can be easily moved into plperl now, but what should be do with the existing ones,
namelyjsonb_plperl and bool_plperl ?
> If we leave them where they are, it would be hard to explain why some transforms are inside plperl while other ones
liveseparately. If we move them into plperl also, wouldn’t it break some compatibility?
It's kind of a mess, indeed. But I think we could make plperl 1.1
contain the additional transforms and just tell people they have
to drop the obsolete extensions before they upgrade to 1.1.
Fortunately, it doesn't look like functions using a transform
have any hard dependency on the transform, so "drop extension
jsonb_plperl" followed by "alter extension plperl update" should
work without cascading to all your plperl functions.
Having said that, we'd still be in the position of having to
explain why some transforms are packaged with plperl and others
not. The distinction between built-in and contrib types might
be obvious to us hackers, but I bet a lot of users see it as
pretty artificial. So maybe the existing packaging design is
fine and we should just look for a way to reduce the code
duplication.
regards, tom lane