On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin <alexk@commandprompt.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.