On 1/14/18, Tom Lane <t...@sss.pgh.pa.us> wrote: > So, for each catalog header pg_foo.h, there would be a > generated file, say pg_foo_d.h, containing: > > * Natts_ and Anum_ macros for pg_foo > > * Any EXPOSE_TO_CLIENT_CODE sections copied from pg_foo.h > > * Any OID-value macros for entries in that catalog
I'm on board in principle, but I have some questions: How do we have the makefiles gracefully handle 62 generated headers which need to be visible outside the backend? Can I generalize the approach I took for the single OIDs file I had, or is that not even the right way to go? (In short, I used a new backend make target that was invoked in src/common/Makefile - the details are in patch v6-0006) If we move fmgr oid generation here as you suggested earlier, I imagine we don't want to create a lot of #include churn. My idea is to turn src/include/utils/fmgroids.h into a static file that just #includes catalog/pg_proc_d.h. Thoughts? And I'm curious, what is "_d" intended to convey? (While I'm thinking outloud, I'm beginning to think that these headers lie outside the scope of genbki.pl, and belong in a separate script.) -John Naylor