Re: Libpq support for precision and scale

Fernando Nasser wrote:
> Bruce Momjian wrote:
> > 
> > I have reviewed this patch and clearly has features I would like to get
> > into 7.3.  We have been pushing too much type knowledge into apps and
> > this will give people a libpq solution that we can manage.  Here are my
> > comments.
> > 
> 
> We definitively want this to go into 7.3.  I am planning on update
> this patch next week.

Great.

> > I hesitate to add another PQexec function.  That could complicate the
> > API.
> > 
> 
> We have agreed to add another call to set a flag for including the
> metadata on the PQexec call (which would make it work like the
> PQexecIncludeMetadata described above).  It will be in the REPOST patch.
> 
> Question: should it affect only the next PQexec(), or should we require
> the user to reset it?
> 
> How do we call it?  I am thinking of  PQsetIncludeMetadata()
> Name suggestions for this call are welcome.

Uh, is it more efficient to do the setting before the query is called? 
If so, I guess is would remain active until you turn off off.  That
seems the clearest.  I like the separate function to turn it on.

> > > The PGconn parameter would be reasonable for retrieving metadata
> > > about table columns, for instance.
> > 
> > I think this is the way to go.  We just require the connection be valid.
> > If it isn't, we throw an error.  I don't see this as a major restriction.
> > In fact, it would be interesting to just call this function
> > automatically when someone requests type info.
> > 
> 
> Sorry but we disagree on this one.  The metadata is related (part of)
> a result, which is a different object, with a different life spam.
> There is no way to be certain that the connection is still around
> and no reliable way of testing for it.   If the conn field is a
> dangling pointer any check based on it depends on that heap memory
> not being realocated already.  Well, we could keep a list of results
> associated with a connection and go cleaning the conn pointers in it 
> _if_ the user uses PQfinish() properly.  A little bit dangerous IMO.
> 
> I would stick with Tom Lane's decision of deprecating pconn and leave
> the metadata independent of it.

Oh, no reliable way to determine the error;  that is bad.

Does your new PQsetIncludeMetadata() eliminate the need for the
connection pointer?  If so, it is clearly better than the connection
parameter as you suggest.  I guess I am getting confused.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@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