From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] pg_sleep(interval) |
Date: | 2013-08-16 23:52:27 |
Message-ID: | 16727.1376697147@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 8/16/13 3:35 PM, Robert Haas wrote:
>> On Fri, Aug 16, 2013 at 2:57 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
>>> Except there are no data types that can be cast to both double and
>>> interval currently.
>> That, unfortunately, is not sufficient to avoid a problem.
> That example can be used as an argument against almost any kind of
> overloading.
True. I think the gripe here is that pg_sleep('42') has worked for
many releases now, and if we add this patch then it would suddenly
stop working. How common is that usage likely to be (probably not
very), and how useful is it to have a version of pg_sleep that
takes an interval (probably also not very)?
Since the same effect can be had by writing a user-defined SQL function,
I'm a bit inclined to say that the value-added by having this as a
built-in function doesn't justify the risk of breaking existing apps.
It's a close call though, because both the risk and the value-added seem
rather small from here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Cronenworth | 2013-08-16 23:56:45 | Fix Windows socket error checking for MinGW |
Previous Message | Bruce Momjian | 2013-08-16 20:57:25 | Re: 9.4 regression |