[PATCH] - Provide robust alternatives for replace_string
Georgios <gkokolatos@protonmail.com>
From: Georgios <gkokolatos@protonmail.com>
To: "pasim@vmware.com" <pasim@vmware.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-31T12:25:02Z
Lists: pgsql-hackers
Attachments
- 0001-Use-stringInfo-instead-of-char-in-replace_string.patch (application/octet-stream) patch 0001
- 0001-Heap-allocated-string-version-of-replace_string.patch (application/octet-stream) patch 0001
Hi, In our testing framework, backed by pg_regress, there exists the ability to use special strings that can be replaced by environment based ones. Such an example is '@testtablespace@'. The function used for this replacement is replace_string which inline replaces these occurrences in original line. It is documented that the original line buffer should be large enough to accommodate. However, it is rather possible and easy for subtle errors to occur, especially if there are multiple occurrences to be replaced in long enough lines. Please find two distinct versions of a possible solution. One, which is preferred, is using StringInfo though it requires for stringinfo.h to be included in pg_regress.c. The other patch is more basic and avoids including stringinfo.h. As a reminder stringinfo became available in the frontend in commit (26aaf97b683d) Because the original replace_string() is exposed to other users, it is currently left intact. Also if required, an error can be raised in the original function, in cases that the string is not long enough to accommodate the replacements. Worthwhile to mention that currently there are no such issues present in the test suits. It should not hurt to do a bit better though. //Asim and Georgios
Commits
-
Refactor pg_get_line() to expose an alternative StringInfo-based API.
- 8e3c58e6e459 14.0 landed
-
Remove arbitrary line length limits in pg_regress (plain and ECPG).
- 784b1ba1a2b9 14.0 landed
-
Remove arbitrary restrictions on password length.
- 67a472d71c98 14.0 cited