| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: move hex_decode() to /common so it can be called from frontend |
| Date: | 2020-12-25 01:47:33 |
| Message-ID: | 20201225014733.GC21105@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Fri, Dec 25, 2020 at 09:04:41AM +0900, Michael Paquier wrote:
> Looks like the defense put in place by 6b1c5ca has allowed to catch up
> a bug here. When base64 has been copied from encode.c to src/common/
> for SCRAM (newlines should not be handled by SCRAM, hence the copy),
> we have done the same. The copied code just returns -1 for error
> paths. For this case, I think that you should also prefix those
> functions with "pg_", and also include the encode part for
> completeness.
I now understand the wisdom of your suggestion. Attached is a patch
that removes hex_decode from ecpg properly, and returns -1 from the
/common version.
--
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
| Attachment | Content-Type | Size |
|---|---|---|
| hex.diff | text/x-diff | 5.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-12-25 02:20:27 | Re: pgsql: move hex_decode() to /common so it can be called from frontend |
| Previous Message | Michael Paquier | 2020-12-25 00:04:41 | Re: pgsql: move hex_decode() to /common so it can be called from frontend |