From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
Date: | 2014-04-14 19:39:40 |
Message-ID: | 31076.1397504380@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> What is the difference (on affected platforms) between
> Datum funcname(PG_FUNCTION_ARGS);
> and writing (effectively)
> PGDLLEXPORT Datum funcname(PG_FUNCTION_ARGS);
> Datum funcname(PG_FUNCTION_ARGS);
> or for that matter
> Datum funcname(PG_FUNCTION_ARGS);
> PGDLLEXPORT Datum funcname(PG_FUNCTION_ARGS);
According to
http://www.postgresql.org/message-id/52D25AA2.50108@2ndquadrant.com
the latter fails outright. Which is problematic because that'd be the
more common case (particularly if you put manually-written externs in a
header file). So while we could do this, and it'd probably be an
improvement in the very long run, it'd definitely cause pain in the short
run. Not sure if it's worth it.
I still wish we could get rid of this problem by fixing the Windows build
recipes so that the PGDLLEXPORT marking wasn't needed. We proved to
ourselves recently that getting rid of PGDLLIMPORT on global variables
wouldn't work, but I'm not sure that the function end of it was really
investigated.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-04-14 20:16:37 | Re: JSONB in-place updates? |
Previous Message | Fabrízio de Royes Mello | 2014-04-14 19:31:47 | Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements |