On Fri, 7 Nov 2025 at 01:47, Mats Kindahl wrote:
> > I agree with Amit that there doesn't seem to be a need to free
> > pubnames.data. We're already leaking publist, for instance. This is
> > okay since we only call these functions during DDL, which in general is
> > not sensitive to leaks.
>
>
On 11/6/25 13:40, Álvaro Herrera wrote:
On 2025-Nov-06, Mats Kindahl wrote:
Attached is a proposal that instead of building error message and hints
dynamically, it will use ereport() directly and as a result does not have to
allocate the error message strings and error message hints dynamically
On 2025-Nov-06, Mats Kindahl wrote:
> Attached is a proposal that instead of building error message and hints
> dynamically, it will use ereport() directly and as a result does not have to
> allocate the error message strings and error message hints dynamically and
> these can be removed.
LGTM, t
On 11/6/25 13:09, Amit Kapila wrote:
On Thu, Nov 6, 2025 at 5:24 PM David Rowley wrote:
On Fri, 7 Nov 2025 at 00:38, Mats Kindahl wrote:
As discussed in [1] the functions check_publications_origin_tables() and
check_publications_origin_sequences() are building error messages using
dynamically
On Thu, Nov 6, 2025 at 5:24 PM David Rowley wrote:
>
> On Fri, 7 Nov 2025 at 00:38, Mats Kindahl wrote:
> > As discussed in [1] the functions check_publications_origin_tables() and
> > check_publications_origin_sequences() are building error messages using
> > dynamically allocated StringInfo ins
On Fri, 7 Nov 2025 at 00:38, Mats Kindahl wrote:
> As discussed in [1] the functions check_publications_origin_tables() and
> check_publications_origin_sequences() are building error messages using
> dynamically allocated StringInfo instances only to avoid duplicating a
> call of ereport().
Looks
