| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
| Cc: | o(dot)tselebrovskiy(at)postgrespro(dot)ru, pgsql-hackers(at)postgresql(dot)org, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> |
| Subject: | Re: Error in calculating length of encoded base64 string |
| Date: | 2023-06-09 06:13:45 |
| Message-ID: | 310915.1686291225@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gurjeet Singh <gurjeet(at)singh(dot)im> writes:
> On Thu, Jun 8, 2023 at 7:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This bug is very ancient, dating to commit 79d78bb26 which
>> added encode.c. (The other instances were presumably copied
>> from there.) Still, it doesn't quite seem worth back-patching.
> Is it worth investing time in trying to unify these 3 occurrences of
> base64 length (and possibly other relevant) code to one place? If yes,
> I can volunteer for it.
I wondered about that too. It seems really silly that we made
a copy in src/common and did not replace the others with calls
to that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Smith | 2023-06-09 07:27:51 | Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15 |
| Previous Message | Gurjeet Singh | 2023-06-09 06:10:03 | Re: Error in calculating length of encoded base64 string |