Thread: Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically
Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically
From
Peter Eisentraut
Date:
On 1/17/17 3:07 PM, Tom Lane wrote: > Alternatively ... is there a specific reason why you chose to make > builtins.h the key inclusion file for this change, rather than having > callers include fmgrprotos.h directly? It seems like the stuff remaining > in builtins.h is just a laundry list of random utility functions. > Maybe dispersing those to other headers is the thing to do. Here is a patch that moves two blocks from builtins.h into separate header files. That avoids having to include nodes/pg_list.h and utils/sortsupport.h. The remaining inclusion of nodes/nodes.h is for the oidparse() function. I think that could be moved out of oid.c and put somewhere near parser/ or objectaddress.c. But the practical savings from avoiding nodes.h is probably near zero, so I haven't done anything about that here. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > Here is a patch that moves two blocks from builtins.h into separate > header files. That avoids having to include nodes/pg_list.h and > utils/sortsupport.h. Seems like a reasonable solution. > The remaining inclusion of nodes/nodes.h is for the oidparse() function. > I think that could be moved out of oid.c and put somewhere near parser/ > or objectaddress.c. But the practical savings from avoiding nodes.h is > probably near zero, so I haven't done anything about that here. Agreed, not much value in that. regards, tom lane