David G. Johnston wrote:
> > 2. A stored procedure can decide dynamically of
> > the structure of the resultset(s) it returns,
> > and the caller will discover it as they're returned, not
> > before.
> >
>
> The function itself doesn't care - this concern is about SELECT vs CALL
> invocation only, not the script definition.
It does care, because CREATE FUNCTION has a RETURNS clause and
matching RETURN statements in the body, whereas CREATE PROCEDURE
doesn't and (will?) have a different syntax for producing resultsets.
For instance in the patch [1] I mentioned earlier, that particular syntax
was the DB2-inspired
"DECLARE c1 CURSOR WITH RETURN FOR SELECT * FROM cp_test2"
As for the invocation, that's just the starting point. At this point
the driver doesn't know from '{call x}' whether x is a procedure or a
function in Postgres, hence the request for a syntax that would work
for both. Okay, but aside from that, if there are results, the driver
needs to get them in a way that works without knowing wether it's a
function or procedure. How would that happen?
Back to the first message of the thread, Shay Rojansky was saying:
"However, connecting via Npgsql, which uses the extended protocol, I
see something quite different. As a response to a Describe PostgreSQL
message, I get back a NoData response rather than a RowDescription
message"
Why would a Describe on a "CALL myproc()" even work if we
accept the premise that myproc() does not advertise what it may return,
contrary to a "SELECT * FROM function()"?
This issue goes beyond a "syntactic bridge" between CALL and SELECT.
[1]
https://www.postgresql.org/message-id/4580ff7b-d610-eaeb-e06f-4d686896b...@2ndquadrant.com
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
