Peter Eisentraut writes:
> On 2/5/13 3:47 PM, Alvaro Herrera wrote:
>> Patch attached.
> This has broken cpluspluscheck:
> ./src/include/access/rmgrlist.h:28:8: error: expected constructor,
> destructor, or type conversion before '(' token
cpluspluscheck has an explicit exclusion for kwlist.h,
On 2/5/13 3:47 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>
>>> The
>>> approach in the second patch is to turn these into "extern const RmgrId"
>>> instead, and use a second inclusion of rmgrlist.h in rmgr.c that assigns
>>> them the values as consts.
>>
>> ... but I d
Alvaro Herrera writes:
> Patch attached.
Seems like a couple of the comments could use updates:
>* Note: RM_MAX_ID could be as much as 255 without breaking the XLOG file
>* format, but we keep it small to minimize the size of RmgrTable[].
This is no longer particularly sensible, since w
Tom Lane wrote:
> Alvaro Herrera writes:
> > The
> > approach in the second patch is to turn these into "extern const RmgrId"
> > instead, and use a second inclusion of rmgrlist.h in rmgr.c that assigns
> > them the values as consts.
>
> ... but I don't especially like that implementation, as it
Alvaro Herrera writes:
> Tom Lane wrote:
>> Couldn't we do something similar to the design for SQL keyword constants,
>> wherein the actual data is in macros in a header file (providing exactly
>> one source of truth for each RM) and then various .c files can #include
>> that after #defining the m
Tom Lane wrote:
> Couldn't we do something similar to the design for SQL keyword constants,
> wherein the actual data is in macros in a header file (providing exactly
> one source of truth for each RM) and then various .c files can #include
> that after #defining the macro as they need?
Here are
Tom Lane wrote:
> Alvaro Herrera writes:
> > pg_xlogdump needs access to the *_desc functions for each rmgr. We
> > already moved forward quite a bit by splitting those functions out of
> > their containing files; so now they are compilable separately. Good.
> > The remaining task is enabling th
On 2013-02-04 17:27:39 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > pg_xlogdump needs access to the *_desc functions for each rmgr. We
> > already moved forward quite a bit by splitting those functions out of
> > their containing files; so now they are compilable separately. Good.
> > The
Alvaro Herrera writes:
> pg_xlogdump needs access to the *_desc functions for each rmgr. We
> already moved forward quite a bit by splitting those functions out of
> their containing files; so now they are compilable separately. Good.
> The remaining task is enabling the code to find those funct
Simon Riggs wrote:
> On 4 February 2013 20:57, Alvaro Herrera wrote:
>
> > pg_xlogdump needs access to the *_desc functions for each rmgr. We
> > already moved forward quite a bit by splitting those functions out of
> > their containing files; so now they are compilable separately. Good.
> > Th
On 4 February 2013 20:57, Alvaro Herrera wrote:
> pg_xlogdump needs access to the *_desc functions for each rmgr. We
> already moved forward quite a bit by splitting those functions out of
> their containing files; so now they are compilable separately. Good.
> The remaining task is enabling th
Hi,
pg_xlogdump needs access to the *_desc functions for each rmgr. We
already moved forward quite a bit by splitting those functions out of
their containing files; so now they are compilable separately. Good.
The remaining task is enabling the code to find those functions in the
first place; cu
12 matches
Mail list logo
