Re: allow building trusted languages without the untrusted versions
От | Tom Lane |
---|---|
Тема | Re: allow building trusted languages without the untrusted versions |
Дата | |
Msg-id | 2476507.1657741774@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: allow building trusted languages without the untrusted versions (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: allow building trusted languages without the untrusted versions
|
Список | pgsql-hackers |
Nathan Bossart <nathandbossart@gmail.com> writes: > Given the discussion in this thread, I intend to mark the commitfest entry > as Withdrawn shortly. Before I do, I thought I'd first check whether 0001 > [0] might be worthwhile independent of $SUBJECT. This change separates the > [un]trusted handler and validator functions for PL/Perl so that we no > longer need to inspect pg_language to determine whether to use the trusted > or untrusted code path. I was surprised to learn that you can end up with > PL/PerlU even if you've specified the trusted handler/validator functions. > Besides bringing things more in line with how PL/Tcl does things, this > change simplifies function lookup in plperl_proc_hash. I suppose such a > change might introduce a compatibility break for users who are depending on > this behavior, but I don't know if that's worth worrying about. Meh. Avoiding the potential repeat hashtable lookup is worth something, but I'm not sure I buy that this is a semantic improvement. ISTM that lanpltrusted *should* be the ultimate source of truth on this point. My feelings about it are not terribly strong either way, though. regards, tom lane
В списке pgsql-hackers по дате отправления: