Re: Libpq support for precision and scale

Fernando Nasser <fnasser@redhat.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