Re: Freezing localtimestamp and other time function on some value

On 12.04.2016 18:01, Adrian Klaver wrote:
> On 04/12/2016 07:36 AM, Alex Ignatov wrote:
>> On 12.04.2016 16:57, George Neuner wrote:
>>> On Tue, 12 Apr 2016 13:50:11 +0300, Alex Ignatov
>>> <a.ignatov@postgrespro.ru> wrote:
>>>
>>>> Is there any method to freeze localtimestamp and other time function
>>>> value.
>>>> Say after freezing on some value sequential calls to these functions
>>>> give you the same value over and over again.
>>>> This  is useful primarily for testing.
>>>>
>>>> In oracle there is alter system set fixed_date command. Have Postgres
>>>> this functionality?
>>> I'm missing how this is useful.   Even having such a feature there is
>>> not any way to duplicate a test trace: execution time of a request is
>>> not guaranteed even if it's issue time is repeatable wrt some epoch.
>>> And if there are concurrent requests, their completion order is not
>>> guaranteed.
>>>
>>> It is also true in Oracle, and in every general purpose DBMS that I
>>> know of.  So what exactly do you "test" using a fixed date/time?
>>>
>>> George
>>>
>>>
>>>
>>
>> This is useful if your application written say on stored function on PG
>> and it works differently on working days and on vacations or weekends.
>> How can you test your application without this ability? Changing system
>
> I do it by having the date be one of the function arguments and have
> the default be something like current_date. When I test I supply a
> date to override the default. This allows for testing the various
> scenarios by changing the supplied date.
>
>> time and affect all application on server or write your own
>> localtimestamp implementation keep in mind of test functionality?
>> Also yesterday we have issue while comparing Pg function output
>> converted from Oracle and its Oracle equivalent on the same data. You
>> now what -  we cant do it, because function depends on
>> localtimestamp(Pg) and sysdate (Ora) =/
>
> Because the Postgres and Oracle servers are on different machines and
> are getting different times, because the time functions return
> different values from the same time. or something else?
>
>>
>>
>
>
 >>Because the Postgres and Oracle servers are on different machines and
are getting different times, because the time functions return different
values from the same time. or something else?

  Because while test we ran this function on different time. And you
cant start it in exactly one time even on same server.

 >>I do it by having the date be one of the function arguments and have
the default be something like current_date. When I test I supply a date
to override the default. This allows for testing the various scenarios
by changing the supplied date.

With that approach you have to say application programmer - 'Hey dude,
please edit this piece of code for my purpose and after that rollback
it'.  I think that it is unacceptable in large project...

--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company