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
