I've submitted this patch to the open CommitFest
https://commitfest.postgresql.org/action/patch_view?id=245
Tim.
On Wed, Nov 25, 2009 at 03:36:25PM +, Tim Bunce wrote:
> Following on from my earlier draft plperl.c refactoring patch, here's a
> new version that's complete (from my perspective
On Mon, Nov 30, 2009 at 12:50:41PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
>> In summary, changing between multiplicity and non-multiplicity libperls
>> after building postgresql isn't safe or supported.
>
> OK, good. Are you adding a check at load time that the library loaded is
> what
Tim Bunce wrote:
In summary, changing between multiplicity and non-multiplicity libperls
after building postgresql isn't safe or supported.
OK, good. Are you adding a check at load time that the library loaded is
what we expect?
cheers
andrew
--
Sent via pgsql-hackers mailing list (
On Sat, Nov 28, 2009 at 09:35:10AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
>> - Changed MULTIPLICITY check from runtime to compiletime.
>> No loads the large Config module.
>
> ISTM the trouble with this is that it assumes that the library that we
> compile with is the same as the li
Tim Bunce wrote:
- Changed MULTIPLICITY check from runtime to compiletime.
No loads the large Config module.
ISTM the trouble with this is that it assumes that the library that we
compile with is the same as the library loaded at runtime. But there is
no guarantee of that at all.
P
Following on from my earlier draft plperl.c refactoring patch, here's a
new version that's complete (from my perspective at least).
I've started work on the enhancements to plperl I outlined on pg-general
(in the "Wishlist of PL/Perl Enhancements for 8.5" thread).
I have a working implementation o
