Re: Freezing localtimestamp and other time function on some value

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Freezing localtimestamp and other time function on some value
Дата
Msg-id CAKFQuwZhjTAuSrenRSfyWYh5nn1hAfcjXHU-kwPEuX25xffrUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freezing localtimestamp and other time function on some value  (Alex Ignatov <a.ignatov@postgrespro.ru>)
Список pgsql-general
On Tue, Apr 12, 2016 at 10:14 AM, Alex Ignatov <a.ignatov@postgrespro.ru> wrote:


On 12.04.2016 19:45, David G. Johnston wrote:
On Tue, Apr 12, 2016 at 8:37 AM, Alex Ignatov <a.ignatov@postgrespro.ru> wrote:

On 12.04.2016 18:01, Adrian Klaver wrote:

>>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...

​ CREATE FUNCTION do_some_date_based_stuff(reference_date date, other_args) [...]

CREATE FUNCTION production_wrapper_for_above(other_args) [...]
AS $$
SELECT do_some_date_based_stuff(now(), other_args);
$$ ​;

Easy to test do_some_date_based_stuff since it has fewer if any external dependencies.  Shouldn't need to test the wrapper that simply calls the "do_some..." with a default value of the current date.

You might be able to define an appropriate function signature that avoids having to write the wrapper though regardless there is no need to have a different environment for testing versus production if approached in this manner.  You just need to decide on the most desirable way to make it work.

David J.


I know that we can always write some wrappers etc, etc.
This approach would failed if your do_some_date_based_stuff have no date args and contains calls say to now()(or other time function what possible can have fix value ) inside it.


This makes no sense and I'm not sure how to explain it better.  The point is for any functions where you think you need to "freeze/specify" time​ you write the procedure function so that is always uses a caller-specified reference time.  If you want to provide access to the logic without requiring the caller to supply a reference time then do so.  Or just make callers supply the time they care about.  But you'd never put "now()" into such a function - wherever you would use "now()" you'd use the argument date instead.  IOW, we don't support the feature in question so you have to modify code if you want similar functionality in PostgreSQL.

Also wrappers lead to  multiple code base,yours client side code needs to know what function  we should use - test or production. Also with your approach  application server needs to know its working mode test / prod

You always should keep in mind that your application may run in test mode (future/past time) and maintain this code. While with my proposal you  can always use some time function(now or localtimestamp or whatever)  which you can  freeze at anytime on DB level, not operation system(using some 3rd libs) or application(using wrappers and other hacks).


​My proposal has nothing to do with test versus development.  Both are always present and the choice of which function to call​
 
​is up to the code needing to perform the work.

I'm not sure what you are looking for here.  PostgreSQL doesn't have this particular feature.  You can either convince others to write it, write it yourself and work to get it committed, or learn a new approach to solving the problem that you describe.  My intent is to aiding effort toward the third option.

David J.

В списке pgsql-general по дате отправления:

Предыдущее
От: Alex Ignatov
Дата:
Сообщение: Re: Freezing localtimestamp and other time function on some value
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Freezing localtimestamp and other time function on some value