On 27/02/16 15:43, Tom Lane wrote:
Chapman Flack <c...@anastigmatix.net> writes:
On 02/27/16 08:37, �lvaro Hernández 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.
Why would it be so much work? Creating a function list, and maybe
documenting those, doesn't sound like a daunting task.
I wouldn't mind volunteering for this work, but I guess I would
need some help to understand and identify the candidate parts of the
API. If anyone could help me here, please let me know.
Álvaro
--
Álvaro Hernández Tortosa
-----------
8Kdata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
