Re: [HACKERS] SQL procedures

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] SQL procedures
Дата
Msg-id CA+TgmoaFBWbV_ukwAokKaOUE_bk0f58sKKjd5gQ5SO4sgYjwVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] SQL procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] SQL procedures  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Jan 2, 2018 at 11:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Anyway, I think it would be better to invent an explicit way to
>> represent whether something is a procedure rather than relying on
>> overloading prorettype to tell us.
>
> +1 --- seems like a new bool column is the thing.  Or may we should merge
> "proisprocedure" with proisagg and proiswindow into an enum prokind?
> Although that would break some existing client-side code.

Assuming that we're confident that "procedure" is mutually exclusive
with "aggregate" and "window function", that seems like the right way
to go.  And I think that's probably the case, both because we're
deciding not to let procedures be called from SELECT statements
(though Oracle apparently does) and because we've chosen syntax that
suggests distinctness: CREATE AGGREGATE, CREATE FUNCTION, CREATE
PROCEDURE.  Window functions are less distinct from the others, since
they go through CREATE FUNCTION, but it still seems unlikely that we'd
ever want to try to support a "window procedure".

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


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] SQL procedures