| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Quirk |
| Date: | 2006-12-11 16:37:22 |
| Message-ID: | 13194.1165855042@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I suspect this is unnecessary, that the only reason cursors can't hold locks
> is because we don't support the kind of read-write operations that clients may
> expect to be able to issue against read-write cursors?
I think the rationale is that the SQL spec defines what DECLARE CURSOR
... FOR UPDATE should mean, and it is not what it would mean in PG if
we simply removed that error check. If we allow it with PG semantics,
we'll be creating an upward compatibility gotcha for ourselves when
we do finally get around to implementing UPDATE ... WHERE CURRENT OF.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2006-12-11 16:47:15 | Vacuum, analyze, and setting reltuples of pg_class |
| Previous Message | Tom Lane | 2006-12-11 16:26:14 | Re: unixware and --with-ldap |