Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Clean up some minor gcc warnings. I'm not touching the
>> major one, though, which is the truly ugly stores into libpq private
>> storage. Can't you find a better way to do this?
> Yes, very ugly. I need some way to store my state information _inside_
> the Result structure. Any ideas?
One possibility is to add an application-defined field, say of void*
type, to PGconn and PGresult, plus set/get access functions for them.
This'd be a fairly general-purpose feature; I've seen it done in other
libraries that export objects of this sort.
On the other hand, if libpq did have such a feature, it'd be nice if
libpgeasy didn't commandeer it but left it open for the application
to use. So maybe we need something else for libpgeasy.
Since libpgeasy is new in the (core) distribution for this release,
perhaps it is not too late to consider an API change? If get_result,
set_result and friends returned a pointer to a two-element struct
(PGresult* and tuplenumber) instead of a raw PGresult*, the problem
would go away. More or less anyway ... I'm not quite sure where it'd
be OK to free() such a struct ...
regards, tom lane