Re: [PATCH] Supporting +-Infinity values by to_timestamp(float8)

17.03.2016 06:27, Vitaly Burovoy:
> On 2016-03-15, David Steele <david@pgmasters.net> wrote:
>> On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
>>> On 3/4/16, Anastasia Lubennikova <a.lubennikova@postgrespro.ru> wrote:
>>>
>>>> I think that you should update documentation. At least description of
>>>> epoch on this page:
>>>> http://www.postgresql.org/docs/devel/static/functions-datetime.html
>>> Thank you very much for pointing where it is located (I saw only
>>> "to_timestamp(TEXT, TEXT)").
>>> I'll think how to update it.
>> Vitaly, have you decided how to update this yet?
> Yes, there are three versions:
> * remove mentioning how to get timestamptz from UNIX stamp;
> * leave a note how to get timestamptz and add a note that such
> encapsulation existed prior to 9.6;
> * replace to the proposed current behavior (without interval).
>
> I decided to implement the third case (but a result there has a time
> zone which can be different, so the result can be not exactly same for
> a concrete user). If a committer decides to do somehow else, he is
> free to choose one from the list above or to do something else.
>
>>>> 3. (nitpicking) I don't sure about "4STAMPS" suffix. "4" is nice
>>>> abbreviation, but it seems slightly confusing to me.
>>> It doesn't matter for me what it is called, it is short enough and
>>> reflects a type on which it is applied.
>>> What would the best name be for it?
>> Anastasia, any suggestions for a better name, or just leave it as is?
>>
>> I'm not in favor of the "4", either.  I think I would prefer
>> JULIAN_MAXYEAR_STAMP.
> It turns out that Tom has changed almost one third of timestamp.h and
> now the constant has a name "TIMESTAMP_END_JULIAN".
>
> I've rebased the patch to the current master (5db5146) and changed it
> according to the new timestamp.h.
>
> Now it passes both versions (integer and float timestamps).
> I deleted test for the upper boundary for integer timestamps, changed
> a little comments.
>
> I decided to delete hints about minimum and maximum allowed values
> because no one type has such hint.
>
> Please find attached a new version of the patch.
>

I think, I should write something as a reviewer.
I read the patch again and I don't see any issues with it.
It applies to the master and works as expected. So I'll mark it as 
"Ready for committer"

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company