Re: [HACKERS] SQL procedures

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] SQL procedures
Date: 2018-01-02 18:45:17
Message-ID: CA+TgmoaFBWbV_ukwAokKaOUE_bk0f58sKKjd5gQ5SO4sgYjwVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 2, 2018 at 11:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-01-02 18:57:25 Re: [HACKERS] SQL procedures
Previous Message Peter Eisentraut 2018-01-02 18:25:44 Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME