diff options
| author | David Rowley <drowley@postgresql.org> | 2023-10-09 15:53:16 +1300 |
|---|---|---|
| committer | David Rowley <drowley@postgresql.org> | 2023-10-09 15:53:16 +1300 |
| commit | 77db132637661f6e01497959128fb650330552b4 (patch) | |
| tree | 89647a2e5f24942886072c90578c10c40543e2eb /src/backend/utils/adt/array_userfuncs.c | |
| parent | 82a7132f531b8b12e77d17476e9bfd599c3c30cf (diff) | |
| download | postgresql-77db132637661f6e01497959128fb650330552b4.tar.gz postgresql-77db132637661f6e01497959128fb650330552b4.zip | |
Remove debug_print_rel and replace usages with pprint
Going by c4a1933b4, b33ef397a and 05893712c (to name just a few), it seems
that maintaining debug_print_rel() is often forgotten. In the case of
c4a1933b4, it was several years before anyone noticed that a path type
was not handled by debug_print_rel(). (debug_print_rel() is only
compiled when building with OPTIMIZER_DEBUG).
After a quick survey on the pgsql-hackers mailing list, nobody came
forward to admit that they use OPTIMIZER_DEBUG. So to prevent any future
maintenance neglect, let's just remove debug_print_rel() and have
OPTIMIZER_DEBUG make use of pprint() instead (as suggested by Tom Lane).
If anyone wants to come forward to claim they make use of
OPTIMIZER_DEBUG in a way that they need debug_print_rel() then they have
around 10 months remaining in the v17 cycle where we could revert this.
If nobody comes forward in that time, then we can likely safely declare
debug_print_rel() as not worth keeping.
Discussion: https://postgr.es/m/CAApHDvoCdjo8Cu2zEZF4-AxWG-90S+pYXAnoDDa9J3xH-OrczQ@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/array_userfuncs.c')
0 files changed, 0 insertions, 0 deletions