On 02/19/2018 05:06 PM, Tom Lane wrote:
> Sebastien FLAESCH <sf@4js.com> writes:
>> On 02/16/2018 04:15 PM, Tom Lane wrote:
>>> You could try running it through the typmodout function for the column's
>>> datatype. I don't offhand know of any built-in types for which that would
>>> be a really plausible typmod, though. Are you sure your client code isn't
>>> mistakenly narrowing it to int16 somewhere?
>
>> As I wrote in my initial mail, I do the following:
>
>> #define VARHDRSZ 4
>> int pgfmod = PQfmod(st->pgResult, i);
>> int pgprec = (pgfmod >> 16);
>> int pgscal = ((pgfmod - VARHDRSZ) & 0xffff);
>> int pgleng = (pgfmod - VARHDRSZ);
>
> That might --- I don't recall offhand --- be the right decoding for
> the typmod of a column of type NUMERIC. It's certainly not right
> for any other datatype. Also, you don't seem to be accounting for
> the fact that negative typmod always means "no typmod specified".
>
> regards, tom lane
>
Thank you Tom.
From our tests it seems to be ok to extract the time/timestamp scale...
This really needs clarification, I would appreciate that the community gives
more information about PQfmod()...
We implement a proprietary database interface lib based on libpq, which needs
to provide columnn type information (similar to ODBC's SQLDescriceCol[W]())
Type information is also used to properly do data type conversions (for ex to
fetch a time(n) into a varchar(50) variable in our language),
It is mission critical for us.
=> I will have a look at psqlODBC ...
Seb