Re: PostgreSQL extension API? Documentation? - Mailing list pgsql-hackers

From Álvaro Hernández Tortosa
Subject Re: PostgreSQL extension API? Documentation?
Date
Msg-id 56D1AE6F.5000109@8kdata.com
Whole thread Raw
In response to Re: PostgreSQL extension API? Documentation?  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
List 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 by date:

Previous
From: Chapman Flack
Date:
Subject: Re: PostgreSQL extension API? Documentation?
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.