Re: PostgreSQL extension API? Documentation?

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(at)8kdata(dot)com <mailto:aht(at)8kdata(dot)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