Alexander Korotkov writes:
> On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule wrote:
>> I marked this patch as ready for committer.
> The last version of the patch still provides transform for builtin
> type in a separate extension. As discussed upthread such transforms
> don't need separate exten
út 27. 2. 2024 v 21:03 odesílatel Alexander Korotkov
napsal:
> Hi!
>
> On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule
> wrote:
> > I marked this patch as ready for committer.
>
> The last version of the patch still provides transform for builtin
> type in a separate extension. As discussed upthr
Hi!
On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule wrote:
> I marked this patch as ready for committer.
The last version of the patch still provides transform for builtin
type in a separate extension. As discussed upthread such transforms
don't need separate extensions, and could be provided as
Hi
út 30. 1. 2024 v 18:35 odesílatel Pavel Stehule
napsal:
>
>
> út 30. 1. 2024 v 18:26 odesílatel Dagfinn Ilmari Mannsåker <
> ilm...@ilmari.org> napsal:
>
>> Pavel Stehule writes:
>>
>> > út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker <
>> > ilm...@ilmari.org> napsal:
>> >
>> >> P
út 30. 1. 2024 v 18:26 odesílatel Dagfinn Ilmari Mannsåker <
ilm...@ilmari.org> napsal:
> Pavel Stehule writes:
>
> > út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker <
> > ilm...@ilmari.org> napsal:
> >
> >> Pavel Stehule writes:
> >>
> >> > út 30. 1. 2024 v 17:18 odesílatel Dagfinn I
Pavel Stehule writes:
> út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker <
> ilm...@ilmari.org> napsal:
>
>> Pavel Stehule writes:
>>
>> > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker <
>> > ilm...@ilmari.org> napsal:
>> >
>> >> Pavel Stehule writes:
>> >>
>> >> > út 30.
út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker <
ilm...@ilmari.org> napsal:
> Pavel Stehule writes:
>
> > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker <
> > ilm...@ilmari.org> napsal:
> >
> >> Pavel Stehule writes:
> >>
> >> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn I
Pavel Stehule writes:
> út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker <
> ilm...@ilmari.org> napsal:
>
>> Pavel Stehule writes:
>>
>> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker <
>> > ilm...@ilmari.org> napsal:
>> >
>> >> Pavel Stehule writes:
>> >>
>> >> > I inse
út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker <
ilm...@ilmari.org> napsal:
> Pavel Stehule writes:
>
> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker <
> > ilm...@ilmari.org> napsal:
> >
> >> Pavel Stehule writes:
> >>
> >> > I inserted perl reference support - hstore_
Pavel Stehule writes:
> út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker <
> ilm...@ilmari.org> napsal:
>
>> Pavel Stehule writes:
>>
>> > I inserted perl reference support - hstore_plperl and json_plperl does
>> it.
>> >
>> > +<->/* Dereference references recursively. */
>> > +<->whil
út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker <
ilm...@ilmari.org> napsal:
> Pavel Stehule writes:
>
> > I inserted perl reference support - hstore_plperl and json_plperl does
> it.
> >
> > +<->/* Dereference references recursively. */
> > +<->while (SvROK(in))
> > +<-><-->in = SvRV(
Pavel Stehule writes:
> I inserted perl reference support - hstore_plperl and json_plperl does it.
>
> +<->/* Dereference references recursively. */
> +<->while (SvROK(in))
> +<-><-->in = SvRV(in);
That code in hstore_plperl and json_plperl is only relevant because they
deal with non-scalar valu
Hi
so 6. 1. 2024 v 16:51 odesílatel vignesh C napsal:
> On Fri, 21 Jul 2023 at 02:59, Ivan Panchenko wrote:
> >
> > Friday, 14 July 2023, 23:27 +03:00 от Tom Lane :
> >
> > =?UTF-8?B?SXZhbiBQYW5jaGVua28=?= writes:
> > > Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut <
> pe...@eisentrau
On Fri, 21 Jul 2023 at 02:59, Ivan Panchenko wrote:
>
> Friday, 14 July 2023, 23:27 +03:00 от Tom Lane :
>
> =?UTF-8?B?SXZhbiBQYW5jaGVua28=?= writes:
> > Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut <
> > pe...@eisentraut.org >:
> >> If the transform deals with a built-in type, then th
>Friday, 14 July 2023, 23:27 +03:00 от Tom Lane :
>
>=?UTF-8?B?SXZhbiBQYW5jaGVua28=?= < w...@mail.ru > writes:
>> Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut <
>> pe...@eisentraut.org >:
>>> If the transform deals with a built-in type, then they should just be
>>> added to the respect
=?UTF-8?B?SXZhbiBQYW5jaGVua28=?= writes:
> Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < pe...@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
>Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < pe...@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 matt
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 interfa
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Andrew Dunstan writes:
>> On 2023-06-22 Th 16: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 matt
Andrew Dunstan writes:
> On 2023-06-22 Th 16: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) ...
>>
>>
>
> Yeah, that's a bit of a mess. Not s
On 2023-06-22 Th 16: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) ...
Yeah, that's a bit of a mess. Not sure what we can do about it now.
chee
>
> So I decided to propose a simple transform extension to pass bytea as
> native Perl octet strings.
Quick review, mostly housekeeping things:
* Needs a rebase, minor failure on Mkvcbuild.pm
* Code needs standardized formatting, esp. bytea_plperl.c
* Needs to be meson-i-fied (i.e. add a "meson
>Среда, 22 марта 2023, 12:45 +03:00 от Daniel Gustafsson :
>
>> On 18 Mar 2023, at 23:25, Иван Панченко < w...@mail.ru > wrote:
>>
>> Hi,
>> PostgreSQL passes bytea arguments to PL/Perl functions as hexadecimal
>> strings, which is not only inconvenient, but also memory and time consuming.
> On 18 Mar 2023, at 23:25, Иван Панченко wrote:
>
> Hi,
> PostgreSQL passes bytea arguments to PL/Perl functions as hexadecimal
> strings, which is not only inconvenient, but also memory and time consuming.
> So I decided to propose a simple transform extension to pass bytea as native
> Perl o
24 matches
Mail list logo
