Re: Moving other hex functions to /common
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-01-12T02:26:51Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rework refactoring of hex and encoding routines
- aef8948f38d9 14.0 landed
Attachments
- v5-0001-Refactor-hex-code.patch (text/x-diff) patch v5-0001
On Mon, Jan 11, 2021 at 11:27:30AM -0500, Bruce Momjian wrote: > Sure, I realize the elog/pg_log is odd, but the alternatives seem worse. I guess that it depends on the use cases. If there is no need to worry about shared libraries, elog/pg_log would do just fine. > You can take ownership of my hex patch and just add to it. I know you > already did the hex length part, and have other ideas of what you want. OK, thanks. I have been looking at it, and tweaked the patch as per the attached. That's basically what you did on the following points: - Use size_t for the arguments, uint64 as return result. - Leave ECPG out of the equation. - Use pg_log()/elog() to report failures in src/common/, rather than error codes. - Renamed the arguments of encode.c to src, srclen, dst, dstlen. The two only things that were not present are the set of checks for overflows, and the adjustments for varlena.c. The first point makes the code of encode.c safer, as previously the code would issue a FATAL *after* writing out-of-bound data. Now it issues an ERROR before any overwrite is done, and I have added some assertions as an extra safety net. For the second, I think that it makes the allocation pattern easier to follow, similarly to checksum manifests. Thoughts? -- Michael