| From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: First feature patch for plperl - draft [PATCH] |
| Date: | 2009-12-04 19:11:12 |
| Message-ID: | 91840DBA-3D85-4A61-BE4D-A3B72C6F122B@kineticode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Dec 4, 2009, at 11:05 AM, Tom Lane wrote:
>> So, do we look for another way to provide the functionality besides
>> having a GUC, or is the functionality itself bad?
>
> I don't think we want random Perl code running inside the postmaster,
> no matter what the API to cause it is. I might hold my nose for "on
> load" code if it can only run in backends, though I still say that
> it's a badly designed concept because of the uncertainty about who
> will run what when. Shlib load time is not an event that ought to be
> user-visible.
So only the child processes would be allowed to load the code? That could make connections even slower if there's a lot of Perl code to be added, though that's also the issue we have today. I guess I could live with that, though I'd rather have such code shared across processes.
If it's a badly designed concept, do you have any ideas that are less bad?
Best,
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-12-04 19:13:28 | Re: First feature patch for plperl - draft [PATCH] |
| Previous Message | David E. Wheeler | 2009-12-04 19:09:36 | Re: First feature patch for plperl - draft [PATCH] |