| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: [HACKERS] SQL procedures |
| Date: | 2017-11-22 19:39:50 |
| Message-ID: | CADkLM=dQY=p13Mk-3gNpRLGBm3mQaLHqEFjzMJh_rTjchoo-Pw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
> T-SQL procedures returns data or OUT variables.
>
> I remember, it was very frustrating
>
> Maybe first result can be reserved for OUT variables, others for multi
> result set
>
>
It's been many years, but if I recall correctly, T-SQL returns a series of
result sets, with no description of the result sets to be returned, each of
which must be consumed fully before the client can move onto the next
result set. Then and only then can the output parameters be read. Which was
very frustrating because the OUT parameters seemed like a good place to put
values for things like "result set 1 has 205 rows" and "X was false so we
omitted one result set entirely" so you couldn't, y'know easily omit entire
result sets.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2017-11-22 19:47:56 | Re: [HACKERS] SQL procedures |
| Previous Message | Ashwin Agrawal | 2017-11-22 19:32:56 | Re: [HACKERS] Commits don't block for synchronous replication |