Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]
Date: 2015-02-23 06:33:38
Message-ID: CAB7nPqRDLwZ=7qQOSdU0LQz4nxJBhR_0O3frjmF3E-pw0Df3KQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 22, 2015 at 6:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After some more hacking, the only remaining uses of foo[1] in struct
> declarations are:
>
> 1. A couple of places where the array is actually the only struct member;
> for some unexplainable reason gcc won't let you use flexible array syntax
> in that case.

Yes. Thanks for adding notes at those places.

> 2. struct sqlda_struct in ecpg's sqlda-native.h. We have a problem with
> using [FLEXIBLE_ARRAY_MEMBER] there because (1) pg_config.h isn't (and I
> think shouldn't be) #included by this file, and (2) there is very possibly
> application code depending on sizeof() this struct; the risk of breaking
> such code seems to outweigh any likely benefit. Also, despite that
> I tried changing [1] to [] and fixing the places I could find that
> depended on sizeof(struct sqlda_struct), but I apparently can't find them
> all because the ecpg regression tests fell over :-(.

Yeah, I think we can live with that. The rest of the backend code is
clean now, and the allocation calculations are more understandable.

> Anyway, barring excitement in the buildfarm I think this project is
> complete.

Thanks!
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2015-02-23 08:28:04 Re: [REVIEW] Re: Compression of full-page-writes
Previous Message Michael Paquier 2015-02-23 06:27:03 Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)