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.
