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.
It is possible to replace many occurrences of builtins.h with
fmgrprotos.h. I just tried this
git grep -l 'include.*utils/builtins.h' -- *.c | xargs perl -pi -e
's{utils/builtins.h}{utils/fmgrprotos.h}'
There's a large number of changes that the oneliner produces that must
be reverted for the compile to be silent, but a large portion can
remain. (I only tried src/backend/access).
Anyway I support the idea of creating other header files for specific
purposes, such as ruleutils.h, varlena.h, etc. (I am against creating a
header file that contains commonly used macros such as
CStringGetTextDatum together with varstr_sortsupport. I think the
latter should have its own place).
--
Álvaro Herrera https://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
