| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Grant Finnemore <grantf(at)guruhut(dot)co(dot)za> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: First draft of new FE/BE protocol spec posted for comments |
| Date: | 2003-04-16 14:23:09 |
| Message-ID: | 17783.1050502989@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-interfaces |
Grant Finnemore <grantf(at)guruhut(dot)co(dot)za> writes:
> As it currently stands, we have functions that are capable of returning
> multi-column rows. Would the result of a FunctionCall message be to return
> a FunctionCallResult and optional RowDescription, RowData messages?
Frankly, I'd remove the whole fastpath function thing if I had my
druthers, but I don't want to reimplement libpq's large-object routines.
I'm just planning to leave it as supporting a scalar return value.
I should mark it deprecated in the docs, probably. You can get the same
results more cleanly by doing a SELECT --- and if the overhead is what's
bothering you, there's PREPARE.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shridhar Daithankar | 2003-04-16 14:25:43 | Re: cross-db queries (was Are we losing momentum?) |
| Previous Message | Dave Page | 2003-04-16 14:20:19 | pg_clog woes with 7.3.2 - Episode 2 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-04-16 15:05:49 | Re: [INTERFACES] First draft of new FE/BE protocol spec posted for comments |
| Previous Message | Tom Lane | 2003-04-16 14:16:49 | Re: [GENERAL] Problem about pgsql's column alias |