From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Moving other hex functions to /common |
Date: | 2021-01-11 16:27:30 |
Message-ID: | 20210111162730.GC4320@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 11, 2021 at 04:45:14PM +0900, Michael Paquier wrote:
> On Wed, Jan 06, 2021 at 08:58:23AM -0500, Bruce Momjian wrote:
> > Fine. Do you want to add the overflow to the patch I posted, for all
> > encoding types?
>
> Yeah. It looks that it would be good to be consistent as well for
> escape case, so as it is possible to add a dstlen argument to struct
> pg_encoding for the encoding and decoding routines. I would also
Sure.
> prefer the option to remove the argument "data" from the encode and
> decode length routines for the hex routines part of src/common/, even
> if it forces the creation of two small wrappers in encode.c to call
> the routines of src/common/. Would you prefer if I send a patch by
Agreed. Having an argument that does nothing is odd.
> myself? Please note that anything I'd send would use directly elog()
> and pg_log() instead of returning status codes for the src/common/
> routines, and of course not touch ECPG, as that's the approach you are
> favoring.
Sure, I realize the elog/pg_log is odd, but the alternatives seem worse.
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.
My key management patch needs the hex encoding in /common, so it will
wait for the application of your patch.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-01-11 17:22:13 | Re: Key management with tests |
Previous Message | Tom Lane | 2021-01-11 16:20:53 | Re: Add Nullif case for eval_const_expressions_mutator |