Re: PGDLLIMPORT: patch or not to patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: George Tarasov <george(dot)v(dot)tarasov(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: PGDLLIMPORT: patch or not to patch
Date: 2021-06-29 20:49:33
Message-ID: 503622.1624999773@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

George Tarasov <george(dot)v(dot)tarasov(at)gmail(dot)com> writes:
> 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?

Our policy so far has been to add PGDLLIMPORT to variables for which
someone makes a case that an extension would have a reasonable use
for it. The bar's not terribly high, but it does exist. The idea of
just doing a blanket s/extern/extern PGDLLIMPORT/g has been discussed
and rejected, because we don't want to commit to supporting absolutely
every global variable as something that's okay for extensions to touch.

So if you've got specific proposals (such as "Mode"), bring them up
on pgsql-hackers.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2021-06-29 21:10:37 Re: Overlapping timestamptz ranges with priority
Previous Message Natália Braz 2021-06-29 20:22:45 Unable to isntall