Re: First feature patch for plperl - draft [PATCH]
От | David E. Wheeler |
---|---|
Тема | Re: First feature patch for plperl - draft [PATCH] |
Дата | |
Msg-id | 91840DBA-3D85-4A61-BE4D-A3B72C6F122B@kineticode.com обсуждение исходный текст |
Ответ на | Re: First feature patch for plperl - draft [PATCH] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: First feature patch for plperl - draft [PATCH]
|
Список | 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 ofPerl code to be added, though that's also the issue we have today. I guess I could live with that, though I'd rather havesuch code shared across processes. If it's a badly designed concept, do you have any ideas that are less bad? Best, David
В списке pgsql-hackers по дате отправления: