Re: overriding current_timestamp - Mailing list pgsql-hackers

From Tom Lane
Subject Re: overriding current_timestamp
Date
Msg-id 12854.1330008102@sss.pgh.pa.us
Whole thread Raw
In response to overriding current_timestamp  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> For (unit) testing, I have often had the need to override the current
> timestamp in the database system.  For example, a column default,
> function, or views would make use of the current timestamp in some way,
> and to test the behavior, it's sometimes useful to tweak the current
> timestamp.

> What might be a good way to do that?

> Just overwrite xactStartTimestamp?  Is that safe?  If it weren't static,
> a user-loaded function could do it.

I think it's safe enough if you can figure out where/when to do it.  Do
you need this to happen invisibly, or is it okay to require the test
script to call a set-the-timestamp function in each transaction?
If the former, it'd likely be necessary to hook into the transaction
start/end hooks.

> Overwrite pg_catalog.now() in the test database?

Yeah, that would work too if you'd rather do it at that end.

> Some semi-official support for this sort of thing would be good.

Mumble.  It's not hard to think of applications where monkeying with the
system clock would amount to a security breach.  So I'm not that excited
about providing a way to do it even semi-officially.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: foreign key locks, 2nd attempt
Next
From: Robert Haas
Date:
Subject: Re: VACUUM ANALYZE is faster than ANALYZE?