Subject: Re: Type scale returned by PQfmod() 65531 for time/timestamp output
 parameter?
To: pgsql-interfaces@lists.postgresql.org
References: <093e1214-7057-f80c-5c3c-74076b7bb555@4js.com>
 <7537.1518711940@sss.pgh.pa.us>
From: Sebastien FLAESCH <sf@4js.com>
Organization: Four Js Development Tools
Message-ID: <f80e250d-b13f-0852-2a11-03218588092f@4js.com>
Date: Fri, 16 Feb 2018 09:56:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <7537.1518711940@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 02/15/2018 05:25 PM, Tom Lane wrote:
> Sebastien FLAESCH <sf@4js.com> writes:
>> When using a stored function returning output parameters defined with as time[(n)]
>> or timestamp[(n)], PQfmod() always returns the same SCALE (65531/0xFFFB), no matter
>> what time/timestamp precision is used.
> 
> Your misunderstanding is in assuming that typmod decoration on function
> parameters means anything.  It doesn't; the function is effectively just
> declared as taking or returning plain time or timestamp.
> 
> Perhaps someday that will change, but it'd be a big task with a lot of
> hard decisions to make.  For instance, do we allow creation of both
> f(time(2)) and f(time(4)), and if so what's the rule for choosing which
> one to call?
> 
> 			regards, tom lane
> 
> 

Thanks for this quick answer Tom,

I just wanted to make sure that this is expected.

We can deal with this, by interpreting 65531/0xFFFB as a precision of 5 to match our needs.

Would be nice however to have some clear documentation about PQfmod() interpretation...
What means exactly 65531/0xFFFB?
Unknown time/timestamp fraction of sec precision?


Maybe the way stored function output parameters are returned could be reviewed?

   select * from proc240(101)

Is it possible to cast() output parameters?

I could not find information about using output parameters in:

https://www.postgresql.org/docs/10/static/sql-syntax-calling-funcs.html

Cheers,
Seb