From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oskari Saarenmaa <os(at)ohmu(dot)fi> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Wim Lewis <wiml(at)omnigroup(dot)com> |
Subject: | Re: [PATCH] Make various variables read-only (const) |
Date: | 2014-01-18 20:26:24 |
Message-ID: | 5325.1390076784@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> AFAICT, this change and some similar ones are based on a false assumption.
> It is *not* necessary to replace pointers by fixed-length arrays in order
> to get things into .rodata.
After further experimentation I find that this claim is true when
compiling "normally", but apparently not when using -fpic, at least
not on RHEL6 x86_64. Even when const-ified, the tables in encnames.o
and wchar.o end up in the data segment (though the underlying strings
are not). So if we want a meaningful shrinkage in the size of the data
segment in libpq.so, we'd have to do something similar to what Oskari
proposes.
However, I'm still against doing so; the other points I made before
still apply, and I think on balance fixed-length arrays are still a
bad idea. It seems like a particularly bad idea to expose a limit
on the length of an encoding name as part of the ABI defined by
pg_wchar.h, as the submitted patch did. I'm on board with making
changes like this where they can be argued to improve correctness and
maintainability, but surely moving to fixed-length arrays is the
opposite of that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-01-18 20:38:42 | Re: new json funcs |
Previous Message | Marti Raudsepp | 2014-01-18 19:47:39 | Re: PoC: Partial sort |