Extensions vs. shared procedural language handler functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Extensions vs. shared procedural language handler functions
Дата
Msg-id 27364.1299286724@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Extensions vs. shared procedural language handler functions  (Jan Urbański <wulczer@wulczer.org>)
Re: Extensions vs. shared procedural language handler functions  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
So while hacking away at the PLs-as-extension changes I ran across an
unforeseen complication.  plperl and plpython use the same C function
entry points for both their trusted and untrusted variants.  This is
problematic for making them into extensions, since we need the two
language variants to be different extensions (else you could not install
just one of them) and the extensions can't both own the same handler
function.

I can imagine that someplace down the road we might want to allow
multiple extensions to own the same SQL object; I know that RPMs can
share ownership of files, for comparison.  But today is not that day.

The only easy fix I can see at the moment is to arbitrarily create two
pg_proc entries --- they can both point at the same C function, but
there need to be two of 'em.

Anyone have a different answer?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: wrapping up this CommitFest (was Re: knngist - 0.8)
Следующее
От: Jan Urbański
Дата:
Сообщение: Re: Extensions vs. shared procedural language handler functions