Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Дата | |
Msg-id | 34d269d41002022113t13abb1aeic9afefeb0fd164a9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
|
Список | pgsql-hackers |
On Tue, Feb 2, 2010 at 21:38, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alex Hunsaker <badalex@gmail.com> writes: >> Yeah the both is gross. How about: >> plperl.on_plperl_init >> plperl.on_plperlu_init >> plperl.on_init ? > > I like the first two. The problem of selecting a good name for the > third one is easily solved: don't have it. What would it be except > a headache and a likely security problem? Well its already in. (FYI its also PGC_SIGHUP) I included it here because I wanted to make sure it made sense in context of the other new plperl GUCs. I *think* its there so people can: -"use" the same modules in both -profile both plperl and plperlu code easily (which is really the same point...) The main difference between on_init and the other two is the later get eval()ed in while the former is treated as "perl -e". (Did I get that right Tim? I did not really look over the first patch). Im not sure if there are different consequences for that style... But I would venture its done that way so we can profile any perl interpreter startup stuff we do in plperl.c or the src/pl/plperl/*.pl files. So there might be a reason for it...
В списке pgsql-hackers по дате отправления: