[Fwd: [PATCHES] Libpq support for precision and scale]

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(at)redhat(dot)com>
Subject: [PATCHES] Libpq support for precision and scale
To: pgsql-patches(at)postgresql(dot)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(at)redhat(dot)com>
Fernando Nasser <fnasser(at)redhat(dot)com>