Large argument to RPAD results in std::bad_alloc

[mrigger]

Consider the following statement:

SELECT RPAD('a', 100000000000000000, 0); -- Error: std::bad_alloc

The SELECT results in an error std::bad_alloc, after running for a while. Is this expected? I checked with MySQL, which seems to immediately return NULL for an overly large size argument.

I found this based on commit 11e5161.

[Mytherin]

Interesting! I tried it in MySQL and the limit seems to be 16777216.

SELECT LENGTH(RPAD('a', 16777216, 0));
-- 16777216
SELECT LENGTH(RPAD('a', 16777217, 0));
-- NULL

Looking at the MySQL source code this value seems to occur in a bunch of places, this seems to be a likely culprit:

#define MAX_BLOB_WIDTH 16777216 /**< Default width for blob */

But then, strangely, this does work:

SELECT LENGTH(CONCAT(RPAD('a', 16777216, 0), RPAD('a', 16777216, 0)));
-- 33554432

Anyway, in this case I think rpad should return an error, as the maximum string size our system can handle is 2^31. I think a better way of solving this would be to turn the second argument into type INTEGER, instead of of type BIGINT. Then values of this size could not be passed to rpad in the first place. A bad_alloc can still potentially occur if the user doesn't have 2GB of memory, but that is then the expected behavior.

[hawkfish]

Yes, assign it to me.