Re: Bytea PL/Perl transform
| От | Ivan Panchenko |
|---|---|
| Тема | Re: Bytea PL/Perl transform |
| Дата | |
| Msg-id | 1689349073.74310713@f308.i.mail.ru обсуждение исходный текст |
| Ответ на | Re: Bytea PL/Perl transform (Peter Eisentraut <peter@eisentraut.org>) |
| Ответы |
Re: Bytea PL/Perl transform
|
| Список | pgsql-hackers |
Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut <peter@eisentraut.org>:
On 22.06.23 22:56, Greg Sabino Mullane wrote:> * Do all of these transforms need to be their own contrib modules? So
> much duplicated code across contrib/*_plperl already (and *plpython too
> for that matter) ...
The reason the first transform modules were separate extensions is that
they interfaced between one extension (plpython, plperl) and another
extension (ltree, hstore), so it wasn't clear where to put them without
creating an additional dependency for one of them.
If the transform deals with a built-in type, then they should just be
added to the respective pl extension directly.
Looks reasonable.
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?
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?
В списке pgsql-hackers по дате отправления: