Re: Moving other hex functions to /common

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Moving other hex functions to /common
Date: 2021-01-12 02:26:51
Message-ID: X/0IChOPHd+aYC1w@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v5-0001-Refactor-hex-code.patch text/x-diff 22.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-01-12 02:28:18 Re: pg_dump, ATTACH, and independently restorable child partitions
Previous Message Bruce Momjian 2021-01-12 02:09:47 Re: Key management with tests