Re: [PATCH] pg_sleep(interval)

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.