|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Getting Gen_fmgrtab.pl to generate macros for all pg_proc entries|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Over in  I noted a need for fmgroids.h macros for pg_proc entries
that overload a particular C function. The F_XXX macros seem to be
designed on the assumption that the only thing they're needed for
is to call the function, so you don't really care which SQL alias
you use to get there. That's unhelpful though when you are concerned
with the SQL-level function more than the C function. I seem to recall
that we've run into this before, but up to now have been able to work
A narrow solution would be to revert the policy we just established
(in commit 36b931214) against allowing oid_symbol entries in
pg_proc.dat, and just manually label such entries when we need to refer
to them in the C code. I don't especially care for that though, for
the reasons cited in 36b931214 --- it'll lead to a lot of random
variation in how people refer to pg_proc entries, rather than having
a uniform convention.
I experimented with generating the fmgroids.h macros by using, not
the prosrc field, but the concatenation of the proname and proargtypes
fields. That's guaranteed unique within pg_proc, but it would have
resulted in several hundred required changes in our source tree,
because of common references to F_OIDEQ and suchlike. But I discovered
that we could alter the rule to be "append proargtypes only if proname
is not unique", and that eliminates the pain almost completely: only
two existing code references need to change.
As an additional benefit, we can generate macros for all the bootstrap
pg_proc entries, not only ones that are for C functions; that fixes
another issue noted in .
Hence, I propose the attached. Any objections?
regards, tom lane
|Next Message||Tom Lane||2020-11-01 20:47:45||Getting rid of aggregate_dummy()|
|Previous Message||Dave Cramer||2020-11-01 18:46:39||Re: how to replicate test results in cf-bot on travis|