Horton

Re: Moving other hex functions to /common

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-01-06T13:58:23Z
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 →

  1. Rework refactoring of hex and encoding routines

On Wed, Jan  6, 2021 at 01:10:28PM +0900, Michael Paquier wrote:
> > It was very confusing, and this attached patch fixes all of that.  I
> > also added the pg_ prefix you suggrested.  If we want to add dstlen to
> > all the functions, we have to do it for all types --- not sure it is
> > worth it, now that things are much clearer.
> 
> Overflow protection is very important in my opinion here once we
> expose more those functions.  Not touching ECPG at all and not making
> this refactoring pluggable into shared libs is fine by me at the end
> because we don't have a case for libpq yet, but I object to the lack
> of protection against overflows.

Fine.  Do you want to add the overflow to the patch I posted, for all
encoding types?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee