PGDLLIMPORT: patch or not to patch - Mailing list pgsql-general

From George Tarasov
Subject PGDLLIMPORT: patch or not to patch
Date
Msg-id ca23fd30-0ff3-d7dd-8e7c-caf8de51a2b6@gmail.com
Whole thread Raw
Responses Re: PGDLLIMPORT: patch or not to patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Dear all!

(comment: my question relates only to the development area; so, please, 
re-post to pgsql-hackers if it is allowed).

I use PostgreSQL under Windows quiet often and make my own builds in 
msys2/mingw64 environment. Also I often experiments with the different 
third-party extensions from the community. And as a result I often faces 
with a PGDLLIMPORT macro to link all libraries and extensions with the 
core postgres.exe.

For some extensions it is required to patch core and these extensions 
insert missing PGDLLIMPORTs by itself. Other extensions are not ported 
under Windows and I prepare my own patches (insert PGDLLIMPORTs) to 
adopt its under my build environment and link shared libraries correctly.

My last case was the "extern ProcessingMode Mode;" variable in the 
miscadmin.h which i patched by PGDLLIMPORT macro. I have discovered the 
same modifications in some other extensions.

So, my questions are there any rules / descriptions / agreements inside 
the PostgreSQL Project that define which global variables inside a core 
code should by specified by a PGDLLIMPORT and which should not?? Or 
there is freedom; you need this variable in the extension (under 
Windows), make patch for it yourself! Or there is plan in the community 
that all global non-static variables should be PGDLLIMPORT-ed by default 
in the future?? What the right way to propose the PGDLLIMPORT patch to 
the master and back-ported PostgreSQL code in order to avoid dup patches 
in the extensions?

Thank you!

Regards,
George Tarasov




pgsql-general by date:

Previous
From: Ray O'Donnell
Date:
Subject: Re: Overlapping timestamptz ranges with priority
Next
From: Natália Braz
Date:
Subject: Unable to isntall