| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| 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 00:04:41 |
| Message-ID: | X+UsmYFlBALRMpM7@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Thu, Dec 24, 2020 at 06:16:20PM -0500, Bruce Momjian wrote:
> On Thu, Dec 24, 2020 at 06:14:49PM -0500, Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > move hex_decode() to /common so it can be called from frontend
>>
>> The buildfarm seems pretty unimpressed with this.
>
> Yes, we are working on reverting the ecpg part.
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2020-12-25 01:47:33 | Re: pgsql: move hex_decode() to /common so it can be called from frontend |
| Previous Message | Bruce Momjian | 2020-12-24 23:31:25 | Re: pgsql: revert removal of hex_decode() from ecpg from commit c3826f831e |