Oskari Saarenmaa writes:
> This allows the variables to be moved from .data to .rodata section which
> means that more data can be shared by processes and makes sure that nothing
> can accidentally overwrite the read-only definitions. On a x86-64 Linux
> system this moves roughly 9 kilobytes of p
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
Oskari Saarenmaa writes:
> On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote:
>> -#define DEF_ENC2NAME(name, codepage) { #name, PG_##name }
>> +/* The extra NUL-terminator will make sure a warning is raised if the
>> + * storage space for name is too small, otherwise when strlen(name) ==
I wrote:
> [ speculation about refactoring the API of transformRelOptions ]
This morning I remembered that there's another patch in the queue with
an interest in the API and behavior of transformRelOptions:
https://commitfest.postgresql.org/action/patch_view?id=1318
While I think that one has no
I wrote:
> However, I believe this code was Alvaro's to begin with, so I'd be
> interested in his opinion on how important it is for transformRelOptions
> to allow more than one namespace per call.
> Actually, I'm kind of wondering why the code has a concept of namespaces
> at all, given the fact
Oskari Saarenmaa writes:
> On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote:
>> - Why change the API of transformRelOptions()?
> The comment was changed to reflect the new API, I modified
> transformRelOptions to only accept a single valid namespace to make things
> simpler in the call
On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote:
> On Fri, Dec 20, 2013 at 12:01 PM, Oskari Saarenmaa wrote:
> > This allows the variables to be moved from .data to .rodata section which
> > means that more data can be shared by processes and makes sure that nothing
> > can accidentall
By an odd coincidence, I also decided to try to const-ify libpq
recently, and noticed this thread as I was cleaning up my patch for
submission. For what it's worth, I've attached my patch to this message.
It doesn't move as much data into the text segment as Oskari Saarenmaa's
patch does, but it is
On Fri, Dec 20, 2013 at 12:01 PM, Oskari Saarenmaa wrote:
> This allows the variables to be moved from .data to .rodata section which
> means that more data can be shared by processes and makes sure that nothing
> can accidentally overwrite the read-only definitions. On a x86-64 Linux
> system th
