From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
Date: | 2014-02-15 15:12:17 |
Message-ID: | 52FF83D1.7060207@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/15/14, 12:41 AM, Tom Lane wrote:
> Meh. I don't think that extension authors are really going to appreciate
> changing from "thou shalt declare all thy functions" to "thou shalt
> declare none of them".
This patch does no such thing.
> If the code were such that it wouldn't matter
> whether a manual declaration were provided too, then that wouldn't be a
> big deal --- but you seem to be ignoring the discussion in the one thread
> cited above about PGDLLEXPORT.
In that thread, you argue that requiring PGDLLEXPORT is not acceptable,
so that makes this argument irrelevant.
> Also, surely it is 100% bogus for fmgr.h to be declaring functions not
> actually provided by fmgr.c.
That's the arrangement if you don't have dynamic loading. For dynamic
loading, the question isn't necessarily who provides them, but who
determines the interface for them. There has to be a way for the
postgres backend to say to extension module authors, I'm going to try to
load this function, and this is what it should look like. This case
wasn't envisioned when they designed C in 1970. If you have a better
idea, I'm listening.
> That will create about as many failure
> modes as it removes, not to mention being conceptually wrong.
What failure modes?
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-02-15 15:16:40 | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
Previous Message | Tom Lane | 2014-02-15 15:06:41 | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |