Re: Freezing localtimestamp and other time function on some value

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?

>
>


--
Adrian Klaver
adrian.klaver@aklaver.com