Re: [HACKERS] SQL procedures
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] SQL procedures |
Дата | |
Msg-id | 9a7b749f-6df1-0977-1bf2-0669770df7af@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] SQL procedures (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] SQL procedures
|
Список | pgsql-hackers |
On 01/02/2018 01:45 PM, Robert Haas wrote: > 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". > Yeah, but these things don't feel like they belong in the same category. The fact that we have to ask this question is a symptom of that. A boolean feels more natural to me here, although I acknowledge it will result in a tiny amount of catalog bloat. Tom's point about client-side code is also valid. I don't feel very strongly about it, though. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: