From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL extension API? Documentation? |
Date: | 2016-02-27 14:43:12 |
Message-ID: | 12015.1456584192@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> On 02/27/16 08:37, lvaro Hernndez Tortosa wrote:
>> 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.
> That's an excellent question that repeatedly comes up, in particular
> because of the difference between the way the MSVC linker works on Windows,
> and the way most other linkers work on other platforms.
Yeah. It would be a fine thing to have a document defining what we
consider to be the exposed API for extensions. In most cases we could
not actually stop extension developers from relying on stuff outside the
defined API, and I don't particularly feel a need to try. But it would be
clear to all concerned that if you rely on something not in the API, it's
your problem if we remove it or whack it around in some future release.
On the other side, it would be clearer to core-code developers which
changes should be avoided because they would cause pain to extension
authors.
Unfortunately, it would be a lot of work to develop such a thing, and no
one has wanted to take it on.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-02-27 14:57:36 | Re: [PATH] Correct negative/zero year in to_date/to_timestamp |
Previous Message | Robert Haas | 2016-02-27 14:25:02 | Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests. |