Re: PostgreSQL extension API? Documentation?

Поиск
Список
Период
Сортировка
От Álvaro Hernández Tortosa
Тема Re: PostgreSQL extension API? Documentation?
Дата
Msg-id 56D1AE6F.5000109@8kdata.com
обсуждение исходный текст
Ответ на Re: PostgreSQL extension API? Documentation?  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Список pgsql-hackers


On 27/02/16 15:01, Fabrízio de Royes Mello wrote:


On Sat, Feb 27, 2016 at 10:37 AM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
>
>
>     Hi.
>
>     I have a newbie question for extension development. Extensions provide an entry point, and are dynamically linked to PostgreSQL. But what APIs/functions are really available for extensions to call?
>
>     The most obvious API is SPI. You could also implements hooks. Of course, functions, types, aggregates, whatever. But can an extension call other "internal" PostgreSQL functions? Is there any restriction to what could --or should-- call an extension? Is there any specific API, or any documentation which states what is available to use?
>
>     In other words: what is the API surface exposed by PostgreSQL to extension developers? The assumption is that no PostgreSQL code should be modified, just adding your own and calling existing funcitons.
>

I don't know what kind of problem you want to solve, but maybe you should ask to yourself:

    Good point. I don't know. More precisely: no specific problem as of today. But if I knew all the "exposed API" I could more clearly think of what problems could be solved.

    In other words: I see it's not clear what an extension could "extend". And knowing that would help extension developers to create new solutions.


1) I need to change some current PostgreSQL behavior?

    If that means not changing current code, might well be an option.


2) I need to add a new feature do PostgreSQL without change the current behavior?

Writing a C extension you can access a lot of internal code if it's available internally by .h headers. For example, some time ago I'm thinking to write an extension to show more internal information about autovacuum (internal queue, etc... some like pg_stat_autovaccuum) . But nowadays is impossible without change the core because some internal structures are not exposed, so we should define an internal API to expose this kind of information.

    So, calling any code exposed by the headers is ok for an extension? Is then the set of all .h files the "exposed API"? Or are some of those functions that should never be called?


So depending what problem you want to solve you can write an extension to do that. Then unfortunately the short aswer is "depend".

    Hope that we can find a more general answer :) Thanks for your opinion!

    Álvaro



-- 
Álvaro Hernández Tortosa


-----------
8Kdata

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

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: PostgreSQL extension API? Documentation?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.