From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: arrays as pl/perl input arguments [PATCH] |
Date: | 2011-02-12 07:53:14 |
Message-ID: | AANLkTin-2xz7Pqt1W7SRZ_UT+cT9v6zz=FUjBaZXjgAo@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Attachment | Content-Type | Size |
---|---|---|
pg_to_perl_arrays_v9.patch.gz | application/x-gzip | 17.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2011-02-12 08:39:01 | Re: btree_gist (was: CommitFest progress - or lack thereof) |
Previous Message | YAMAMOTO Takashi | 2011-02-12 07:08:21 | Re: SSI bug? |