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
