>   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, Pennsylvania 19026

Sun, 19 Dec 1999 21:34:32 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [COMMITTERS] pgsql/src/interfaces/libpgeasy (libpgeasy.c)
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

Mon, 20 Dec 1999 10:47:19 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: [COMMITTERS] pgsql/src/interfaces/libpgeasy
	(libpgeasy.c)
> 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, Pennsylvania 19026

Mon, 20 Dec 1999 13:14:51 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re: [COMMITTERS] pgsql/src/interfaces/libpgeasy
	(libpgeasy.c)