Re: [Fwd: [PATCHES] Libpq support for precision and scale] - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [Fwd: [PATCHES] Libpq support for precision and scale]
Date
Msg-id 200202222334.g1MNYr607155@candle.pha.pa.us
Whole thread Raw
In response to [Fwd: [PATCHES] Libpq support for precision and scale]  (Fernando Nasser <fnasser@cygnus.com>)
List pgsql-hackers
Sorry, I see later comments questioning the patch.  Please review and
resubmit:
http://candle.pha.pa.us/cgi-bin/pgpatches2


---------------------------------------------------------------------------

Fernando Nasser wrote:
> This is a patch that was posted some time ago to pgsql-patches and
> no one has commented on it.
> 
> It adds something that JDBC has that is not present in libpq (see below).
> Is it OK for inclusion?
> 
> Regards to all and thanks for your time,
> Fernando
> 
> 
> -------- Original Message --------
> From: Fernando Nasser <fnasser@redhat.com>
> Subject: [PATCHES] Libpq support for precision and scale
> To: pgsql-patches@postgresql.org
> 
> Some programs like utilities, IDEs, etc., frequently need to know the
> precision and scale of the result fields (columns).  Unfortunately
> libpq does not have such routines yet (JDBC does).
> 
> Liam and I created a few ones that do the trick, as inspired by the
> JDBC code. The functions are:
> 
> char *PQftypename(const PGresult *res, int field_num);
> 
> Returns the type name (not the name of the column, as PQfname do).
> 
> 
> int PQfprecision(const PGresult *res, int field_num);
> int PQfscale(const PGresult *res, int field_num);
> 
> Return Scale and Precision of the type respectively.
> 
> 
> Most programs won't need this information and may not be willing
> to pay the overhead for metadata retrieval. Thus, we added
> an alternative function to be used instead of PQexec if one
> wishes extra metadata to be retrieved along with the query
> results:
> 
> PGresult *PQexecIncludeMetadata(PGconn *conn, const char *query);
> 
> It provides the same functionality and it is used in exactly the
> same way as PQexec but it includes extra metadata about the result
> fields.  After this cal, it is possible to obtain the precision,
> scale and type name for each result field.
> 
> 
> The PQftypename function returns the internal PostgreSQL type name.
> As some programs may prefer something more user friendly than the
> internal type names, we've thrown in a conversion routine as well:
> 
> char *PQtypeint2ext(const char *intname);
> 
> This routine converts from the internal type name to a more user
> friendly type name convention.
> 
> 
> More details are in the patch to the SGML documentation that is 
> part of the patch (attached).
> 
> 
> --
> Liam Stewart <liams@redhat.com>
> Fernando Nasser <fnasser@redhat.com>

--  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
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 7.2 stuff
Next
From: Tom Lane
Date:
Subject: Re: elog() proposal