diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-11-02 11:57:28 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-11-02 11:57:28 -0500 |
commit | 8e1f37c07aafd4bb7aa6e1e1982010af11f8b5c7 (patch) | |
tree | 93e0b3994b9a79e4f3342d2a4f74c3547ca7e3d8 /src/backend/executor/execParallel.c | |
parent | fd2997565c6f66837440dd57f5e52b56aa964d14 (diff) | |
download | postgresql-8e1f37c07aafd4bb7aa6e1e1982010af11f8b5c7.tar.gz postgresql-8e1f37c07aafd4bb7aa6e1e1982010af11f8b5c7.zip |
Rethink the generation rule for fmgroids.h macros.
Traditionally, the names of fmgroids.h macros for pg_proc OIDs
have been constructed from the prosrc field. But sometimes the
same C function underlies multiple pg_proc entries, forcing us
to make an arbitrary choice of which OID to reference; the other
entries are then not namable via fmgroids.h. Moreover, we could
not have macros at all for pg_proc entries that aren't for
C-coded functions.
Instead, use the proname field, and append the proargtypes field
(replacing inter-argument spaces with underscores) if proname is
not unique. Special-casing unique entries such as F_OIDEQ removes
the need to change a lot of code. Indeed, I can only find two
places in the tree that need to be adjusted; while this changes
quite a few existing entries in fmgroids.h, few of them are
referenced from C code.
With this patch, all entries in pg_proc.dat have macros in fmgroids.h.
Discussion: https://postgr.es/m/472274.1604258384@sss.pgh.pa.us
Diffstat (limited to 'src/backend/executor/execParallel.c')
0 files changed, 0 insertions, 0 deletions