| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
| Subject: | Re: Practical impediment to supporting multiple SSL libraries |
| Date: | 2006-04-14 21:04:54 |
| Message-ID: | 25819.1145048694@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Right... As I mentioned, the application can use cursors to
> *work-around* this foolishness in libpq but that doesn't really make it
> any less silly.
Before you define libpq's behavior as "foolishness", you really ought to
have a watertight semantics for what will happen in your proposal when a
SELECT fails partway through (ie, after delivering some but not all of
the tuples). In my mind the main reason for all-or-nothing PGresult
behavior is exactly to save applications from having to deal with that
case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2006-04-14 21:19:24 | Re: Is full_page_writes=off safe in conjunction with |
| Previous Message | Tom Lane | 2006-04-14 20:40:13 | Is full_page_writes=off safe in conjunction with PITR? |