>Friday, 14 July 2023, 23:27 +03:00 от Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
>=?UTF-8?B?SXZhbiBQYW5jaGVua28=?= < wao(at)mail(dot)ru > writes:
>> Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < peter(at)eisentraut(dot)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, namely jsonb_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 live separately. 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.
The code duplication between different transforms is not in C code, but mostly in copy-pasted Makefile, *.control, *.sql and meson-build. These files could be generated from some universal templates. But, keeping in mind Windows compatibility and presence of three build system, this hardly looks like a simplification.
Probably at present time it would be better to keep the existing code duplication until plperl 1.1.
Nevertheless, dealing with code duplication is a wider task than the bytea transform, so let me suggest to keep this extension in the present form. If we decide what to do with the duplication, it would be another patch.
The mesonified and rebased version of the transform patch is attached.
>
>regards, tom lane
>
Regards, Ivan