From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Fernando Nasser <fnasser(at)redhat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fernando Nasser <fnasser(at)cygnus(dot)com>, pgsql-hackers(at)postgresql(dot)org, Liam Stewart <liams(at)cygnus(dot)com> |
Subject: | Re: Libpq support for precision and scale |
Date: | 2002-03-08 01:46:41 |
Message-ID: | 200203080146.g281kgU02700@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-08 01:46:51 | Re: Libpq support for precision and scale |
Previous Message | Tatsuo Ishii | 2002-03-08 01:42:19 | Re: point in time recovery and moving datafiles online |