Re: Stored procedures and out parameters

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Shay Rojansky <roji(at)roji(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Stored procedures and out parameters
Date: 2018-08-30 23:45:43
Message-ID: 5B8881A7.3060100@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/30/18 15:35, Robert Haas wrote:
> On Tue, Aug 28, 2018 at 6:30 AM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> CALL compatible with the SQL standard. For example, if you have a
>> function f1(IN a int, OUT b int), you would call it as SELECT f1(x)
>> and the "b" would somehow be the return value. But a procedure call
>> would be CALL p1(x, y), where x and y could be, say, PL/pgSQL
>> variables.

I suppose the key question for most driver writers is going to be,
what does that difference look like at the fe-be protocol level?
PL/pgSQL might be an unrepresentative example for that question,
as it lives in the backend and could have some other way of retrieving
b to store in y. For any remote client, the result still needs to get
back there before the client can apply any "this result gets assigned
to my y variable" semantics, and is there any material difference between
the protocol message sequences that return these results

select foo(1,2);
select * from foo(1,2);
call bar(1,2);

to the client? And, in the parallel universe where functions got
implemented according to the standard, what in that picture would
be different?

-Chap

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-08-31 00:06:00 Re: pg_verify_checksums and -fno-strict-aliasing
Previous Message Tom Lane 2018-08-30 23:37:37 Re: pg_verify_checksums and -fno-strict-aliasing