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@xxxxxxxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
