BUG #19843: decode(..., 'base64url') returns an extra byte for "ab="

The following bug has been logged on the website:

Bug reference: 19843
Logged by: Atish Prakash
Email address: 125atishprak(at)gmail(dot)com
PostgreSQL version: 19rc1
Operating system: Linux x86_64
Description:

decode() with the new base64url format returns a spurious trailing byte when
the input has one '=' where two would be needed:

SELECT decode('ab', 'base64url'); -- \x69
SELECT decode('ab==', 'base64url'); -- \x69
SELECT decode('ab=', 'base64url'); -- \x69b0

Expected: the third query returns \x69, like the other two, or raises an
error.
The base64 format raises "invalid base64 end sequence" for the same input.
The extra byte 0xb0 comes from the leftover bits of 'b' and the padding, and
is not data encoded in the input.

Cause: in pg_base64_decode_internal(), the '=' sets end = 1 and advances pos
to
3. The input then ends, and the "url && pos == 3" branch emits two bytes
without looking at end.

A possible patch is attached
(0001-fix-base64url-decode-short-padding.patch). It
makes the result \x69. Rejecting the input would also be reasonable, and I
have
no preference. Regression tests pass with it on master; it adds no new test.

Found with semantic differential tests. I reproduced and checked the result
myself.