Re: [PATCH] pg_sleep(interval)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] pg_sleep(interval)
Дата
Msg-id CA+TgmoZPKf_Mii9e8jPDjtPPbZNrFWeS_E5Mpx+Fuoc83_7ZGQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] pg_sleep(interval)  (Vik Fearing <vik.fearing@dalibo.com>)
Ответы Re: [PATCH] pg_sleep(interval)  (Vik Fearing <vik.fearing@dalibo.com>)
Список pgsql-hackers
On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing <vik.fearing@dalibo.com> wrote:
> On 10/17/2013 02:42 PM, Robert Haas wrote:
>> On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing <vik.fearing@dalibo.com> wrote:
>>> On 10/17/2013 10:03 AM, Fabien COELHO wrote:
>>>> My guess is that it won't be committed if there is a single "but it
>>>> might break one code or surprise one user somewhere in the universe",
>>>> but I wish I'll be proven wrong. IMO, "returned with feedback" on a 1
>>>> liner is really akin to "rejected".
>>> I have attached here an entirely new patch (new documentation and
>>> everything) that should please everyone.  It no longer overloads
>>> pg_sleep(double precision) but instead add two new functions:
>>>
>>>  * pg_sleep_for(interval)
>>>  * pg_sleep_until(timestamp with time zone)
>>>
>>> Because it's no longer overloading the original pg_sleep, Robert's
>>> ambiguity objection is no more.
>>>
>>> Also, I like how it reads aloud: SELECT pg_sleep_for('5 minutes');
>>>
>>> If people like this, I'll reject the current patch and add this one to
>>> the next commitfest.
>> I find that naming relatively elegant.  However, you've got to
>> schema-qualify every function and operator used in the definitions, or
>> you're creating a search-path security vulnerability.
>>
>
> Good catch.  Updated patch attached.

Committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: updated emacs configuration
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Regression tests failing if not launched on db "regression"