On 3/29/16, Tom Lane wrote:
> Pushed with minor adjustments.
>
> regards, tom lane
>
Thank you very much!
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
Anastasia Lubennikova writes:
> 17.03.2016 06:27, Vitaly Burovoy:
>> 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 a
17.03.2016 06:27, Vitaly Burovoy:
On 2016-03-15, David Steele wrote:
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
On 3/4/16, Anastasia Lubennikova wrote:
I think that you should update documentation. At least description of
epoch on this page:
http://www.postgresql.org/docs/devel/static/functio
Anastasia Lubennikova writes:
> 15.03.2016 22:28, David Steele:
>> I'm not in favor of the "4", either. I think I would prefer
>> JULIAN_MAXYEAR_STAMP.
> This point is related to another patch
> https://commitfest.postgresql.org/9/540/.
> And added to this patch just for compatibility.
> If Tom
On 2016-03-15, David Steele wrote:
> On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
>> On 3/4/16, Anastasia Lubennikova 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
>>
15.03.2016 22:28, David Steele:
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
On 3/4/16, Anastasia Lubennikova 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
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
> On 3/4/16, Anastasia Lubennikova 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 i
On 3/4/16, Anastasia Lubennikova wrote:
> 27.02.2016 09:57, Vitaly Burovoy:
>> Hello, Hackers!
>>
>> I worked on a patch[1] allows "EXTRACT(epoch FROM
>> +-Inf::timestamp[tz])" to return "+-Inf::float8".
>> There is an opposite function "to_timestamp(float8)" which now defined
>> as:
>> SELECT ('e
27.02.2016 09:57, Vitaly Burovoy:
Hello, Hackers!
I worked on a patch[1] allows "EXTRACT(epoch FROM
+-Inf::timestamp[tz])" to return "+-Inf::float8".
There is an opposite function "to_timestamp(float8)" which now defined as:
SELECT ('epoch'::timestamptz + $1 * '1 second'::interval)
Hi,
thank y
On 2/26/16, Vitaly Burovoy wrote:
> Proposed patch implements it.
I'm sorry, I forgot to leave a note for reviewers and committers:
This patch requires CATALOG_VERSION_NO be bumped.
Since pg_proc.h entry has changed, it is important to check and run
regress tests on a new cluster (as if CATALOG
Added to the CF 2016-03:
https://commitfest.postgresql.org/9/546/
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello, Hackers!
I worked on a patch[1] allows "EXTRACT(epoch FROM
+-Inf::timestamp[tz])" to return "+-Inf::float8".
There is an opposite function "to_timestamp(float8)" which now defined as:
SELECT ('epoch'::timestamptz + $1 * '1 second'::interval)
Since intervals do not support infinity values,
12 matches
Mail list logo