On 2014-03-07 13:27:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > A patch fixing this is attached. I've added some more local variables to
> > deal with the longer lines...
>
> Since I've got a compiler in captivity that complains about this,
> I'll take care of checking and committing th
Andres Freund writes:
> A patch fixing this is attached. I've added some more local variables to
> deal with the longer lines...
Since I've got a compiler in captivity that complains about this,
I'll take care of checking and committing this patch.
I still think it might be a good idea to spin u
Hi,
On 2014-03-06 02:39:37 +0100, Andres Freund wrote:
> Unless somebody protests I'll try to get the remaining walsender and
> docs patches ready before sending in the patch fixing this as it's not
> disturbing the buildfarm. I'll be onsite/travelling tomorrow; so I am
> not sure I'll be done the
On 2014-03-05 20:02:56 -0500, Robert Haas wrote:
> On Wed, Mar 5, 2014 at 6:50 PM, Andres Freund wrote:
> Urgh. I know that isn't per project style, but I just plain missed it
> while staring at these patches. At one point I thought of complaining
> that separating the public and private values
On 2014-03-05 20:03:16 -0500, Tom Lane wrote:
> However, this is probably a bit beside the point. I'm quite prepared
> to believe that nobody uses gcc < 4.0 anymore. The question is what
> older non-gcc compilers are still out there, and can we either get hold
> of them for the buildfarm, or trus
Andres Freund writes:
> On 2014-03-05 19:12:15 -0500, Tom Lane wrote:
>> I'm surprised too; I had thought we still had some critters running
>> hoary compilers. We need to do something about that if we actually
>> believe in C90-compiler support.
> What version was the gcc that triggered the err
On Wed, Mar 5, 2014 at 6:50 PM, Andres Freund wrote:
> On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
>> I don't believe that this is legal per C90:
>>
>> typedef struct ReorderBufferChange
>> {
>> XLogRecPtrlsn;
>>
>> /* type of change */
>> union
>> {
>> enum ReorderBu
On 2014-03-05 19:12:15 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
> >> By the time you get done fixing the portability issue, I suspect you
> >> won't have a union at all for the first case.
>
> > You might be right. I'd rather not leak the in
Andres Freund writes:
> On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
>> By the time you get done fixing the portability issue, I suspect you
>> won't have a union at all for the first case.
> You might be right. I'd rather not leak the internal enum values to the
> public though, so there are tw
On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
> I don't believe that this is legal per C90:
>
> typedef struct ReorderBufferChange
> {
> XLogRecPtrlsn;
>
> /* type of change */
> union
> {
> enum ReorderBufferChangeType action;
> /* do not leak internal enum va
I don't believe that this is legal per C90:
typedef struct ReorderBufferChange
{
XLogRecPtrlsn;
/* type of change */
union
{
enum ReorderBufferChangeType action;
/* do not leak internal enum values to the outside */
intaction_internal;
}
11 matches
Mail list logo
