Alvaro Herrera writes:
> For PQclear() specifically, one thing that I thought a few days ago
> would be useful would to have it return (PGresult *) NULL. Then the
> very common pattern of doing "PQclear(res); res = NULL;" could be
> simplified to "res = PQclear(res);", which is nicely compact and
On 2022-Jun-17, Peter Eisentraut wrote:
> From 355ef1a68be690d9bb8ee0524226abd648733ce0 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Fri, 17 Jun 2022 12:09:32 +0200
> Subject: [PATCH v2 3/3] Remove redundant null pointer checks before PQclear
> and PQconninfofree
>
> These function
Michael Paquier writes:
> On Fri, Jun 17, 2022 at 09:03:23PM +0200, Peter Eisentraut wrote:
>> I'm pretty sure PostgreSQL code already depends on this behavior anyway.
>> The code just isn't consistent about it.
> In the frontend, I'd like to think that you are right and that we have
> already so
On Fri, Jun 17, 2022 at 09:03:23PM +0200, Peter Eisentraut wrote:
> I'm pretty sure PostgreSQL code already depends on this behavior anyway.
> The code just isn't consistent about it.
In the frontend, I'd like to think that you are right and that we have
already some places doing that. The backen
Peter Eisentraut writes:
> On 17.06.22 07:11, Tom Lane wrote:
>> Notably, I think the choice
>> that pfree(NULL) is disallowed traces directly to worries about
>> coding-pattern-compatibility with pre-POSIX free(). Should we
>> revisit that?
> Yes please, and also repalloc().
repalloc no, becau
On 17.06.22 07:11, Tom Lane wrote:
Having said that, the pattern "if (x) free(x);" is absolutely
ubiquitous across our code, and so I'm not sure that I'm on
board with undoing it only in libpq. I'd be happier if we made
a push to get rid of it everywhere.
Sure, here is a more comprehensive pat
On 17.06.22 05:25, Michael Paquier wrote:
On Thu, Jun 16, 2022 at 10:07:33PM +0200, Peter Eisentraut wrote:
calls, where the "if" part is unnecessary. This is of course pretty
harmless, but some functions like scram_free() and freePGconn() have become
so bulky that it becomes annoying. So whil
Michael Paquier writes:
> On Thu, Jun 16, 2022 at 10:07:33PM +0200, Peter Eisentraut wrote:
>> calls, where the "if" part is unnecessary. This is of course pretty
>> harmless, but some functions like scram_free() and freePGconn() have become
>> so bulky that it becomes annoying. So while I was d
On Thu, Jun 16, 2022 at 10:07:33PM +0200, Peter Eisentraut wrote:
> calls, where the "if" part is unnecessary. This is of course pretty
> harmless, but some functions like scram_free() and freePGconn() have become
> so bulky that it becomes annoying. So while I was doing some work in that
> area
undertook to simplify this.From f7a10c1fca10c76b89dbf402ad9418ed8f0675d7 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 16 Jun 2022 21:50:56 +0200
Subject: [PATCH] libpq: Remove redundant null pointer checks before free()
---
src/interfaces/libpq/fe-auth-scram.c| 33 ++--
src/
10 matches
Mail list logo
