| From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)atentus(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: pg_stat_reset round 3 |
| Date: | 2002-08-06 14:46:20 |
| Message-ID: | 3D4FE13C.63488852@fourpalms.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
> The CALL syntax Chris is referring to is for Procedures, which we have
> not implemented yet (but I'd love to see us do it). Procedures return
> nothing. They have side efects only. Well, actually, in other DBs there
> are OUT parameters which allow procedures to return values in a limited
> way. And in MSSQL (at least) they can project result sets, which is not
> the same as returning result sets because you can't do anything with
> them like apply a criteria or join with other results.
SQL9x defines IN, OUT, and INOUT parameters on procedures. Now that we
have set returning functions, we might (more easily?) be able to define
tuple-returning procedures which is presumably how we would implement
OUT parameters (similar to how python returns values).
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-08-06 15:01:28 | Re: Better handling of parse errors |
| Previous Message | Gavin Sherry | 2002-08-06 12:39:18 | Re: Better handling of parse errors |