Re: [HACKERS] SQL procedures - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] SQL procedures
Date
Msg-id 9a7b749f-6df1-0977-1bf2-0669770df7af@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] SQL procedures
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] SQL procedures
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] SQL procedures