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

From Peter Eisentraut
Subject Re: [HACKERS] SQL procedures
Date
Msg-id f2b2ac79-f7d0-e736-ac12-50a103d0dcbd@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] SQL procedures
Re: [HACKERS] SQL procedures
List 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] SQL procedures