Обсуждение: Re: [COMMITTERS] pgsql/src/interfaces/libpgeasy (libpgeasy.c)
> Date: Sunday, December 19, 1999 @ 20:31:26 > Author: tgl > > Update of /usr/local/cvsroot/pgsql/src/interfaces/libpgeasy > from hub.org:/home/tmp/cvs-serv86291 > > Modified Files: > libpgeasy.c > > ----------------------------- Log Message ----------------------------- > > 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? Or is this going to be another one of those, "Hey, who put the LIKE indexing in gram.y... Oh, it was you Momjian... Well, no, I can't think of a better way right now..." Two years pass until someone improves it. :-) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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
> 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 ... I hear you. pgeasy was just an attempt to make C programming in PostgreSQL easier. I am not sure how much it will get used, but it seemed valuable, and a number of people were using it when it was in contrib. I figure the storage of the tuple at the end of the status field is harmless enough. Do people have any comments on it? I am willing to move it back into contrib. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026