Re: allowing multiple PQclear() calls

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing multiple PQclear() calls
Date: 2013-01-02 16:36:23
Message-ID: 50E46207.2070500@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013-01-02 17:22 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
>> 2013-01-02 16:52 keltezéssel, Heikki Linnakangas írta:
>>> IMHO this doesn't belong into libpq, the interface is fine as it is. It's the caller's
>>> responsibility to set the pointer to NULL after PQclear(), same as it's the caller's
>>> responsibility to set a pointer to NULL after calling free(), or to set the fd variable
>>> to -1 after calling close(fd). There's plenty of precedence for this pattern, and it
>>> shouldn't surprise any programmer.
>> Let me quote Simon Riggs here:
>>> ... we should introduce a new public API call that is safer,
>>> otherwise we get people continually re-inventing new private APIs that
>>> Do the Right Thing, as the two other respondents have shown.
> Heikki is right and Simon is wrong. This is not a very helpful idea,
> and anybody who wants it is probably doing it already anyway.
>
> There might be some value in the proposed macro if using it reliably
> stopped bugs of this class, but it won't; the most obvious reason being
> that there is seldom only one copy of a given PGconn pointer in an
> application. If you just blindly s/PQfinish(x)/PQfinishSafe(&x)/
> you will most likely be zapping some low-level function's local
> parameter copy, and thus accomplishing nothing of use. You could
> possibly make it work fairly consistently if you changed your entire
> application to pass around PGconn** instead of PGconn*, but that would
> be tedious and somewhat error-prone in itself; and none of the rest of
> libpq's API is at all friendly to the idea.
>
> The context where this sort of thing is actually helpful is C++, where
> it's possible to introduce enough low-level infrastructure that the
> programmer doesn't have to think about what he's doing when using
> indirect pointers like that. You can make a C++ wrapper class that is
> both guaranteed safe (unlike this) and notationally transparent.
> Of course, that has its own costs, but at least the language provides
> some support. So it'd be reasonable for libpqxx to do something like
> this, but it's not very helpful for libpq to do it. As Heikki says,
> there is basically zero precedent for it in libc or other C libraries.
> There's a reason for that.
>
> regards, tom lane

OK, then forget about this patch.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2013-01-02 16:39:04 Re: [COMMITTERS] pgsql: Unify some tar functionality across different parts
Previous Message Tom Lane 2013-01-02 16:36:01 Re: pgsql: Unify some tar functionality across different parts