Robert Haas <robertmh...@gmail.com> writes:
> Most of these files don't have that many entries, and they're not
> modified that often. The elephant in the room is pg_proc.h, which is
> huge, frequently-modified, and hard to decipher. But I think that's
> going to need more surgery than just introducing named constants -
> which would also have the downside of making the already-long lines
> even longer.
I don't think we need "named constants", especially not
manually-maintained ones. The thing that would help in pg_proc.h is for
numeric type OIDs to be replaced by type names. We talked awhile back
about introducing some sort of preprocessing step that would allow doing
that --- ie, it would look into some precursor file for pg_type.h and
extract the appropriate OID automatically. I'm too tired to go find the
thread right now, but it was mostly about building the long-DATA-lines
representation from something easier to edit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
