Albe Laurenz writes:
> Tom Lane wrote:
>> I'm inclined to give this up as a bad job and go back to the
>> previous state. We have a solution that works and doesn't
>> produce warnings; third-party authors who don't want to use it
>> are on their own.
> I think you are right.
Done. We can alway
Tom Lane wrote:
>> Albe Laurenz writes:
>>> Anyway, I have prepared a patch along the lines you suggest.
>>
>> Pushed, we'll see if the buildfarm likes this iteration any better.
>
> And the answer is "not very much". The Windows builds aren't actually
> failing, but they are producing lots of
I wrote:
> Albe Laurenz writes:
> Anyway, I have prepared a patch along the lines you suggest.
> Pushed, we'll see if the buildfarm likes this iteration any better.
And the answer is "not very much". The Windows builds aren't actually
failing, but they are producing lots of warnings:
lquery_op
Albe Laurenz writes:
>> Anyway, I have prepared a patch along the lines you suggest.
Pushed, we'll see if the buildfarm likes this iteration any better.
> It occurred to me that the documentation still suggests that you should
> add a declaration to a C function; I have fixed that too.
I didn't
I wrote:
> Anyway, I have prepared a patch along the lines you suggest.
It occurred to me that the documentation still suggests that you should
add a declaration to a C function; I have fixed that too.
I'll add the patch to the next commitfest.
Yours,
Laurenz Albe
0001-Add-PGDLLEXPORT-to-PG_FU
Tom Lane wrote:
> I poked at this a little bit. AFAICT, the only actual cross-file
> references are in contrib/ltree/, which has quite a few. Maybe we
> could hold our noses and attach PGDLLEXPORT to the declarations in
> ltree.h.
>
> hstore's HSTORE_POLLUTE macro would also need PGDLLEXPORT-ifi
Albe Laurenz writes:
> The buildfarm log at
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips&dt=2016-10-12%2018%3A37%3A26
> shows the build failing (among others) for contrib/tablefunc
> (close to the bottom end of the log).
That's a build of 9.6.
> Now when I look at the source,
Tom Lane wrote:
> No, it's cross *file* references within a single contrib module that
> would be likely to need extern declarations in a header file. That's
> not especially weird IMO. I'm not sure how many cases there actually
> are though.
I went through the contrib moules and tried to look t
I wrote:
> No, it's cross *file* references within a single contrib module that
> would be likely to need extern declarations in a header file. That's
> not especially weird IMO. I'm not sure how many cases there actually
> are though.
I poked at this a little bit. AFAICT, the only actual cross
Craig Ringer writes:
> On 18 October 2016 at 04:11, Tom Lane wrote:
>> As for the core problem, I wonder why we aren't recommending that
>> third-party modules be built using the same infrastructure contrib
>> uses, rather than people ginning up their own infrastructure and
>> then finding out th
Craig Ringer writes:
> On 18 October 2016 at 04:19, Andres Freund wrote:
>> On 2016-10-17 16:16:37 -0400, Robert Haas wrote:
>>> I wouldn't think that cross-file references would be especially
>>> common. Functions that take PG_FUNCTION_ARGS and return Datum aren't
>>> a lot of fun to call from
2016-10-18 5:48 GMT+02:00 Craig Ringer :
> On 18 October 2016 at 04:19, Andres Freund wrote:
> > On 2016-10-17 16:16:37 -0400, Robert Haas wrote:
> >> I wouldn't think that cross-file references would be especially
> >> common. Functions that take PG_FUNCTION_ARGS and return Datum aren't
> >> a
On 18 October 2016 at 04:11, Tom Lane wrote:
> As for the core problem, I wonder why we aren't recommending that
> third-party modules be built using the same infrastructure contrib
> uses, rather than people ginning up their own infrastructure and
> then finding out the hard way that that means
On 18 October 2016 at 04:19, Andres Freund wrote:
> On 2016-10-17 16:16:37 -0400, Robert Haas wrote:
>> I wouldn't think that cross-file references would be especially
>> common. Functions that take PG_FUNCTION_ARGS and return Datum aren't
>> a lot of fun to call from C. But maybe I'm wrong.
>
>
Robert Haas wrote:
Yeah, I don't know. For my money, decorating the function definitions
in place seems easier than having to maintain a separate export list,
especially if it can be hidden under the carpet using the existing
stupid macro tricks. But I am not a Windows expert.
I suppose we sh
17 октября 2016 г. 23:42:30 MSK, Tom Lane wrote:
[ wanders away wondering what cmake does with this... ]
CMake can export all symbols using only one setting -
WINDOWS_EXPORT_ALL_SYMBOLS for shared libraries and special for Postgres I
made "export all" for executable files. You can try this in
On Mon, Oct 17, 2016 at 4:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane wrote:
>>> As for the core problem, I wonder why we aren't recommending that
>>> third-party modules be built using the same infrastructure contrib
>>> uses, rather than people gin
Robert Haas writes:
> On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane wrote:
>> As for the core problem, I wonder why we aren't recommending that
>> third-party modules be built using the same infrastructure contrib
>> uses, rather than people ginning up their own infrastructure and
>> then finding out
On 2016-10-17 16:16:37 -0400, Robert Haas wrote:
> I wouldn't think that cross-file references would be especially
> common. Functions that take PG_FUNCTION_ARGS and return Datum aren't
> a lot of fun to call from C. But maybe I'm wrong.
There's a fair number of DirectFunctionCall$Ns over the ba
On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz
>> wrote:
>>> Actually I would say that the correct solution is to remove the function
>>> declarations from all the header files in contrib, since from commit
>>> e7128e8d
Robert Haas writes:
> On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz
> wrote:
>> Actually I would say that the correct solution is to remove the function
>> declarations from all the header files in contrib, since from commit e7128e8d
>> on the functions are declared by PG_FUNCTION_INFO_V1 anywa
On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz wrote:
> Tom Lane wrote:
>>> Well, the buildfarm doesn't like that even a little bit. It seems that
>>> the MSVC compiler does not like seeing both "extern Datum foo(...)" and
>>> "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in
I wrote:
> But I'd understand if you think that this is too much code churn for too
> little
> benefit, even if it could be considered a clean-up.
>
> In that case, I'd argue that in the sample in doc/src/sgml/xfunc.sgml
> the function definitions should be changed to read
>
> PGDLLEXPORT Datu
Tom Lane wrote:
>> Well, the buildfarm doesn't like that even a little bit. It seems that
>> the MSVC compiler does not like seeing both "extern Datum foo(...)" and
>> "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in
>> a .h file is failing. There is also quite a bit of phas
On 13 Oct. 2016 05:28, "Tom Lane" wrote:
>
> I wrote:
> > Albe Laurenz writes:
> >> Tom Lane wrote:
> >>> I'm okay with adding PGDLLEXPORT to the extern, but we should update
> >>> that comment to note that it's not necessary with any of our standard
> >>> Windows build processes. (For that matt
I wrote:
> Well, the buildfarm doesn't like that even a little bit. It seems that
> the MSVC compiler does not like seeing both "extern Datum foo(...)" and
> "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in
> a .h file is failing. There is also quite a bit of phase-of-the-mo
I wrote:
> Albe Laurenz writes:
>> Tom Lane wrote:
>>> I'm okay with adding PGDLLEXPORT to the extern, but we should update
>>> that comment to note that it's not necessary with any of our standard
>>> Windows build processes. (For that matter, the comment fails to explain
>>> why this macro is p
Albe Laurenz writes:
> Tom Lane wrote:
>> I'm okay with adding PGDLLEXPORT to the extern, but we should update
>> that comment to note that it's not necessary with any of our standard
>> Windows build processes. (For that matter, the comment fails to explain
>> why this macro is providing an exte
Tom Lane wrote:
> I'm okay with adding PGDLLEXPORT to the extern, but we should update
> that comment to note that it's not necessary with any of our standard
> Windows build processes. (For that matter, the comment fails to explain
> why this macro is providing an extern for the base function at
Albe Laurenz writes:
> Tom Lane wrote:
>> Except that we don't. There aren't PGDLLEXPORT markings for any
>> functions exported from contrib modules, and we don't use dlltool
>> on them either. By your argument, none of contrib would work on
>> Windows builds at all, but we have a ton of buildfa
Tom Lane wrote:
>> PostgreSQL itself seems to use export files that explicitly declare the
>> exported symbols, so it gets away without these decorations.
>
> Except that we don't. There aren't PGDLLEXPORT markings for any
> functions exported from contrib modules, and we don't use dlltool
> on t
Albe Laurenz writes:
> Tom Lane wrote:
>> The lack of complaints about this suggest that it's not actually necessary
>> to do so. So what this makes me wonder is whether we can't drop the
>> DLLEXPORT on the finfo function too. I'd rather reduce the number of
>> Microsoft-isms in the code, not i
Tom Lane wrote:
> Albe Laurenz writes:
>> Currently, PG_FUNCTION_INFO_V1 is defined as
[...]
>
>> Is there a good reason why the "funcname" declaration is not decorated
>> with PGDLLEXPORT?
>
> The lack of complaints about this suggest that it's not actually necessary
> to do so. So what this m
Albe Laurenz writes:
> Currently, PG_FUNCTION_INFO_V1 is defined as
> /*
>* Macro to build an info function associated with the given function name.
>* Win32 loadable functions usually link with 'dlltool --export-all', but
> it
>* doesn't hurt to add PGDLLIMPORT in case they don'
Currently, PG_FUNCTION_INFO_V1 is defined as
/*
* Macro to build an info function associated with the given function name.
* Win32 loadable functions usually link with 'dlltool --export-all', but it
* doesn't hurt to add PGDLLIMPORT in case they don't.
*/
#define PG_FUNCTION_INF
35 matches
Mail list logo
