From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQL procedures |
Date: | 2017-11-08 14:21:11 |
Message-ID: | f2b2ac79-f7d0-e736-ac12-50a103d0dcbd@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/31/17 14:23, Tom Lane wrote:
> Putting 0 in prorettype seems like a pretty bad idea.
It seemed like the natural thing to do, since we use a zero OID to
indicate "nothing" in many other places.
> Why not use VOIDOID for the prorettype value?
We need a way to distinguish functions that are callable by SELECT and
procedures that are callable by CALL.
> Or if there is some reason why "void" isn't the
> right pseudotype, maybe you should invent a new one, analogous to the
> "trigger" and "event_trigger" pseudotypes.
I guess that would be doable, but I think it would make things more
complicated without any gain that I can see. In the case of the
pseudotypes you mention, those are the actual types mentioned in the
CREATE FUNCTION command. If we invented a new pseudotype, that would
run the risk of existing code creating nonsensical reverse compilations
like CREATE FUNCTION RETURNS PROCEDURE. Catalog queries using
prorettype == 0 would behave sensibly by default. For example, an inner
or outer join against pg_type would automatically make sense.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-11-08 14:23:46 | Re: SQL procedures |
Previous Message | Robert Haas | 2017-11-08 13:18:41 | Re: why not parallel seq scan for slow functions |