Hello Robert,
- some concerns have been raised that it breaks pg_sleep(TEXT) which currently works thanks to the implicit TEXT -> INT cast. I would suggest to add pg_sleep(TEXT) explicitely, like: CREATE FUNCTION pg_sleep(TEXT) RETURNS VOID VOLATILE STRICT AS $$ select pg_sleep($1::INTEGER) $$ LANGUAGE SQL; That would be another one liner, to update the documentation and to add some tests as well! ISTM that providing "pg_sleep(TEXT)" cleanly resolves the upward-compatibility issue raised.I think that's ugly and I'm not one bit convinced it will resolve all the upgrade-compatibility issues.
Realistically, all sleeps are going to be reasonably well measured in seconds anyway.
I do not know that. From a "usual" dabatabase point of view, it does not make much sense to slow down a database anyway, and this function is never needed... so it really depends on the use case.
If someone want to simulate a long standing transaction to check its effect on some features such as dumping data orreplication or whatever, maybe pg_sleep(INTERVAL '5 hours') is nicer that pg_sleep(18000), if you are not too good at dividing by 60, 3600 or 86400...
If you want to sleep for some other interval, convert that interval to a number of seconds first.
You could say that for any use of INTERVAL. ISTM that the point if the interval type is just to be more readable than a number of seconds to express a delay.
Another problem is that, as written, this is vulnerable to search_path hijacking attacks.
Yes, sure. I was not suggesting to create the function directly as above, this is just the test I made to check whether it worked as I thought, i.e. providing a TEXT version works and interacts properly with the INTEGER and INTERVAL versions. My guess is that the function definition would be inserted directly in pg_proc as other pg_* functions at initdb time.
-- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
