Skip site navigation (1) Skip section navigation (2)

Re: Libpq support for precision and scale

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fernando Nasser <fnasser(at)redhat(dot)com>
Cc: Fernando Nasser <fnasser(at)cygnus(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Libpq support for precision and scale
Date: 2001-11-28 16:18:44
Message-ID: 2427.1006964324@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Fernando Nasser <fnasser(at)redhat(dot)com> writes:
> Tom Lane wrote:
>> These seem okay, but I don't like the API detail that "0 is returned if
>> information is not available".

> This seems to be the libpq convention.  On calls such as PQfsize and
> PQfmod, for instance, zero is a valid result and is also returned if
> the information is not available.

I don't think zero is (or ever will be) a valid PQfsize result.  It was
not a valid PQfmod result at the time the routine was written, either,
although I think that with Thomas' recent changes it might be possible
to see a zero typmod for some of the datetime types.  On the other hand
-1 is a very common valid result for both PQfsize and PQfmod, so these
routines *would* have been broken on day one if they had returned -1.

I don't think consistency with other routines that have different ranges
of valid results is an adequate argument for making an API that's broken
by design.

> P.S.: Maybe whoever originally designed the libpq interface was trying
> to accomplish some sort of "soft fail" by returning zero.

No, they were picking a value that couldn't be mistaken for a valid
result.  At the time, anyway.


>> 2. Make use of the PGconn link that's stored in PGresults, and
>> specify that these functions can only be used on PGresults that
>> came from a still-open connection.

> That field has been deprecated (see comments in the source code) 

I know; I wrote those comments.  But I'd be willing to un-deprecate it
if it seemed the most convenient API for the inquiry functions would
require it.  On the whole though I think passing a PGconn to the
metadata inquiry functions would be the right way to go about this.
Note that there isn't any fundamental reason to require that it be the
same PGconn that was used to acquire the PGresult.  Any connection to
the same database would do fine.  (In fact, for standard types, any
connection to a database of the same PG version would do fine...)

Anyone else have an opinion?

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-11-28 16:23:04
Subject: Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opens up
Previous:From: Doug McNaughtDate: 2001-11-28 16:17:35
Subject: Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opens up

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group