Re: Moving other hex functions to /common - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Moving other hex functions to /common
Date
Msg-id 20210106135823.GD32172@momjian.us
Whole thread Raw
In response to Re: Moving other hex functions to /common  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Moving other hex functions to /common  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Incorrect allocation handling for cryptohash functions with OpenSSL
Next
From: "Tang, Haiying"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist