Search Postgresql Archives

PGDLLIMPORT: patch or not to patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux