Re: arrays as pl/perl input arguments [PATCH]

On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin <alexk(at)commandprompt(dot)com> wrote:
> So, here is the v8. Instead of rewriting the encode_array_literal I've added
> another function, encode_type_literal (could use a better name).
> ...
> I can easily convert the encode_array_literal to just call this function, but
> not encode_array_constructor,
> but I actually wonder what do we need the
> encode_array_constructor (and encode_array_literal) functions for ? I
> guess they were useful to pass array references to SPI,

I dunno, Ill have to go dig through the archives.

> but per my
> understanding it's possible to use perl array references in SPI functions
> directly now, so are there any other use cases for these functions, which
> justify the time to spend on updating them to support arrays of composites

Probably not, but I dunno if we can just drop them out from people using them...

> (and shouldn't we also provide encode_composite_literal and
> encode_composite_constructor as well) ?

Well we should not need encode_composite_literal,
encode_type_literal() should work for that. I don't see a reason for
the _constructor variant so id vote against it unless there is a use
case.

Anyway in playing with this patch a bit more I found another bug
return [[]]; would segfault.

So find attached a v9 that:
- fixes above segfault

- made plperl_sv_to_literal vastly simpler (no longer uses SPI and
calls regtypin directly)

- removed extraneous </para> added in v8 in plperl.sgml (my docbook
stuff is broken, so I can't build them, hopefully there are no other
problems)

- we now on the fly (when its requested) make the backwards compatible
string for arrays (it was a few lines now that we have
plperl_sv_to_literal)

- make plperl.o depend on plperl_helpers.h (should have been done in
the utf8 patch)

Anyway barring any more bugs, I think this patch is ready.