On 2023-Jun-09, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Thu, Jun 8, 2023 at 7:35 AM Tom Lane 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
Tom Lane writes:
> Gurjeet Singh writes:
>> On Thu, Jun 8, 2023 at 7:35 AM Tom Lane 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
Gurjeet Singh writes:
> On Thu, Jun 8, 2023 at 7:35 AM Tom Lane 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
On Thu, Jun 8, 2023 at 7:35 AM Tom Lane wrote:
>
> o.tselebrovs...@postgrespro.ru writes:
> > While working on an extension I've found an error in how length of
> > encoded base64 string is calulated;
>
> Yeah, I think you're right. It's not of huge significance, because
> it just overestimates
o.tselebrovs...@postgrespro.ru writes:
> While working on an extension I've found an error in how length of
> encoded base64 string is calulated;
Yeah, I think you're right. It's not of huge significance, because
it just overestimates by 1 or 2 bytes, but we might as well get
it right. Thanks
Greetings, everyone!
While working on an extension I've found an error in how length of
encoded base64 string is calulated;
This error is present in 3 files across all supported versions:
/src/common/base64.c, function pg_b64_enc_len;
/src/backend/utils/adt/encode.c, function
