Re: Mark all GUC variable as PGDLLIMPORT

po 23. 8. 2021 v 23:08 odesílatel Chapman Flack <chap(at)anastigmatix(dot)net>
napsal:

> On 08/23/21 14:30, Robert Haas wrote:
> > it seems likely that this proposed
> > API would have the exact same problem, because it would let people do
> > exactly the same thing. And, going through this proposed API would
> > still be significantly more expensive than just accessing the bare
> > variables, because you'd at least have to do some kind of lookup based
> > on the GUC name
>
> I think the API ideas in [0] would not let people do exactly the same
> thing.
>
> They would avoid exposing the bare variables to overwrite. Not that
> there has been any plague of extensions going and overwriting GUCs,
> but I think in some messages on this thread I detected a sense that
> in principle it's better if an API precludes it, and that makes sense
> to me.
>
> The second idea also avoids the expense of name-based lookup (except once
> at extension initialization), and in fact minimizes the cost of obtaining
> the current value when needed, by slightly increasing the infrequent cost
> of updating values.
>
>
There are few GUC variables, where we need extra fast access - work_mem,
encoding settings, and maybe an application name. For others I hadn't
needed to access it for over 20 years. But I understand that more complex
extensions like timescaledb will use more internal GUC.

Maybe a new light API based on enum identifiers instead of string
identifiers that ensure relatively fast access (and safe and secure) can be
a good solution. And for special variables, there can be envelope functions
for very fast access. But although the special interface, the
responsibility of the extension's author will not be less, and the C
extensions will not be more trusted, so it is hard to say something about
possible benefits. I am inclined to Robert's opinion, so the current state
is not too bad, and maybe the best thing that is possible now is the
decreasing difference between supported platforms.

Regards

Pavel

>